Re: About component architectures...

On Mon, 29 Apr 2002, Cezary Zielinski wrote:

[...difference between requests from End User vs request from
    Application Builder...]
> I still would not make that distinction. Any configuration request should
> internally within the component block other requests (both other
> configuration and service requests). 

Block, indeed, and hence also synchronization is needed.

> Let us call 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. 

No, I don't think the _interpreter_ should _execute_ the request: it
should translate the request into appropriate requests for the
sub-components, and then set them in action. This is indeed also
`configuration', but at a different level than, for example, the
configuration that involves the sub-components getting running new
algorithms to execute requests.

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

No: one single interpreter is fine with me, but it knows the
difference between its two (or more) `roles'.


> I would not worry about different users. Each one of them would
> simply use a subset of all possible requests. 

But someone has to check whether they are authorised to use the subset
they are using. This is overkill in the simplest kind of applications,
but it is definitely needed for commercial components.

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

Simple code is a good feature; but some applications _require_ more
complex features, that come with more complex code. But mind you: I do
not say that _all_ Orocos components should have the complex features;
they should just be there for people that need them.

Herman

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