Re: A working document

Herman Bruyninckx wrote :

| > Yes, definitely. Codels are made of code, and perform tasks on data that
| > come from elsewhere.
| >
| > The purpose of modules is to give a specification of their interface in
| > terms of functionality, so that the decision procedures can do symbolic
| > reasonning. Besides this, you are free to put what you need into the
| > codels. For instance, I see no problem in sharing the same class between
| > several modules, and thus use a pure object oriented approach _within_
| > codels, to manipulate the structure that are exchanged between the
| > modules.
| 
| Mmmm, I really don't like this too much: you have no encapsulation of
| the data in this way, and that will lead to
| uncontrolled/undeterministic behaviour sooner or later. I mean: a
| codel can not rely on having a consistent view on the data, if this
| data is ``somewhere else''...

Let me try to explain further:

What I meant by data is actually the production of other modules (aka
'posters' in the current version of GenoM).
Basically, posters are shared data structures, which are expected to be
always 'consistent', because every particular poster is produced by a
_single_ module. There are problems in maintaining such a consistency,
but we have begun to work on a framework that solves some problems (we
called this 'data tagging', where tags can be the time of acquisition,
the configuration of a sensor, the position of the robot, etc.).

Thus posters are (or should be :) 'consistent data structures'. Using the
data contained within posters can be done thanks to a library which can
be shared between the producer and the consumer.

Does this match your ideas better?


| This seems to correspond to what I had in mind: the ``dummy user''
| doesn't have to take care about communication, but the ``advanced
| user/application builder'' does. Both use different codels, I guess.

Yes, but 'different codels' does not makes sense to me:

I would distinguish 3 class of user:
. adavanced/application builder (whole system knowledge)
. module developer (single module knowledge)
. dummy user (user of the system/modules, and/or developer of other modules)

Only the first type of user  cares about communication mechanisms (setup,
implementation etc.).
The second type describes its needs in terms of communication (data
structures?).
The third one does not (should not have to) care of communication.

Codels are written by the second class of user (and that's all what is
needed to write a module, besides the interface description). Basically,
you can see codels much like 'callbacks'. codels interface the library
which implements a functionality, and the 'module engine', which should
be standard and common to all modules. The module engine will receive
requests for services, schedule codel execution, spawn threads/tasks and
so on, but this is 'hidden' for the module developper.

Thus there is only one type of codel: it receives data, and structures
the execution of an algorithm. Everything else belongs to the first type
of user.