Re: About component architectures...

On Fri, 26 Apr 2002, Cezary Zielinski wrote:

> 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? 

Yes.

> 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.

Don't forget that we have different interfaces because we have
different users! The Application Builder will want to do explicit
(re)configurations; the End User wants to execute actions, that,
without the End User noticing it, will involve state and parameter
changes in the component. I do think we have to separate both, because
the Application Builder must have the possibility to block a End User
from sending his service requests while he is configuring.

> Do you need to introduce the concept of a supervisor at all? 
I hope not. And in most cases it will not be necessary. But it should
be there if needed.

[...]
> 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.

Indeed we don't want that! But I see where the misunderstanding lies:
my mails were about the _internal_ architecture of a component, not
about the whole system. That's the business of the Application
Builder, not of Orocos :-) Any `supervisor' I talk about is invisible
outside of the components (except maybe for the Application Builders
that need it to, for example, reconfigure the internals of the
component: changing control laws, tune parameters, ...).

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480