Re: A working document

| 1) Does fig.1 imply that all hardware elements (e.g. actuators, sensors) =
| have to be connected  to the upper layers of the system through the =
| operating system? Is no direct connection (i.e. port access) =
| anticipated? My experience is that usually sensors and actuators are not =
| handled by the operating system directly.

It's true that the 'sensors layer' can sometimes bypass the OS (e.g. for
huge data transmissions). However, those mechanisms are provided by
system calls. Thus the OS is still involved, at least for the setup
phase.

It's difficult to choose a good place for the OS in the figure you
mention. Maybe we should draw a single box, made of the two components
'OS' and 'sensors interface'.


| 2) How important do you think time-out is in the case of robotic =
| components?=20

I think you talking about the 'max-time' field of services and codels?
The timeout is only a way to detect failures (e.g. a servoing task that
lasts too much and thus cannot execute properly). Once detected, it is
possible to make the information available for other modules or for the
decision layer.
For instance, a module could run perfectly on a machine with much CPU,
but I could completely fail on another machine, or if the CPU gets
overloaded. 
Not all the components  are interrested in such temporal properties, but
for the lowest (real-time) level, I think it's important. Don't you?


| 3) Are codels pure code? (no data structures). That would imply =
| disjunction between code and data which is contrary to object oriented =
| paradigm, which has its benefits.

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. 


| 4) I would suggest a change in terminology. Instead of using the term =
| "database" I would use the term "component image". Database has a =
| slightly different meaning in computer science. In this case the outside =
| world (other components) percive the component through the exported =
| image. This compnent perceives other components through imported image. =
| Thus we have a component image.

Yes, database is not the good word :). This is rather an _internal_
repository that represents the instataneous value of the parameters of
modules.
However, this repository is not visible to the outside world. What is
visible is the exported data (the production of the module), and the
services that either produce that data or modify the internal parameters.
So I'm not sure that 'component image' applies here?



| 5) The question wether communication should be handled within codels or =
| outside I would answer in favour of - inside. After all we want to hide =
| from the user all the unnecessary details - he/she should concentrate on =
| the task not on the communication details. Maybe special communication =
| codels would do the trick (an intermediate solution).

I completely agree with you on the fact that communication should not be
left to the user (user = module programmer). This is exactly why I think
that communication should _not_ be defined within codels: codels are the
only part the programmer will write. The communication should be handled
by the module internal engine (which is roughly the same for all modules,
and thus it is generic and written only once).
Are you ok with this?