Re: About component architectures...

Am I right to understand that you want to distinguish: configuration of a
component (i.e. changing its internal parameters or state) and service
commands? If that is so, I would prefer not to make this distinction. From a
general point of view they are the same. Service request provides (possibly)
some data and an internal state change as a byproduct, and the
configuration/state change request provides (usually) NULL data and the
needed change of parameters or internal state. To me that is more or less
the same, thus no need to introduce the distinction. This might also
simplify the implementation. Such distinctions usually lead to seperate code
for each of the cases.

Do you need to introduce the concept of a supervisor at all? I would like to
think in a bit different way. We have some form of interacting components.
Some of them provide simple services. Others - using the simple ones -
provide more complex services. At the highest level we have a component
responsible for the execution of the whole task. Nevertheless it is only a
component - if need arises its role can be subsummed by still higher level
components. In this way there is no need to distinguish a supervisor.
Introduction of a supervisor might lead to a misunderstanding that the
framework that we are proposing has a hierarchic structure with a single
element controlling the whole system - and I though that we don't want that.
The framework should be able to produce distributed systems with no or
several supervisors. In such systems their members might communicate
implicitly by simply observing each others actions through external sensors.

Cezary
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos