Re: About component architectures...

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

I still would not make that distinction. Any configuration request should
internally within the component block other requests (both other
configuration and service requests). Such a request would change the mode of
operation of the component. In what I am proposing you have only one - let
us cll it - interpreter of requests. This interpreter not only executes the
requests but also chcnges the internal state of the component. If you make
the distinction you might end up with two different visions and thus
implementations of a component. On the one side you have a configuration
handling component vision and on the other hand you have a service handling
vision of the component. This should lead to two interpreters of requests
and a complicated switching mechanism between them. If on the other hand you
stick to a single interpreter then why make the distinction? I would not
worry about different users. Each one of them would simply use a subset of
all possible requests. Treat the above only as a voice in the discussion,
but maybe it is worth considering? It might lead to the simplification of
the code of the component.

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

OK - now I understand. By the way, the above mentioned interpreters would be
a part of that component supervisor.

Cezary

>
> Herman
>
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480
>
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos