Re: A working document

On Thu, 27 Dec 2001, Cezary Zielinski wrote:

[...about ``component image''...]
> The idea of component images is derived from my papers regarding MRROC++ (I
> think you already have them). There each effector of virtual sensor had an
> associated process dealing with it. Other processes needed information about
> the states of those devices, so some information regarding that had to be
> transferred to them. I decided that the transferred information forms an
> image of a device in another process, and thus effector (robot) images and
> virtual sensor images were formed. Component image would be a generalisation
> of that.

Is there any difference with the data structure part of the
component's interface? To me, both look the same: they present a view
to the `outside world' on the internals of a component.

I also do believe that more than one ``component image'' is needed:
one for the normal user, and another one for the ``supervisor''.

> > > 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 (at first thought) would prefer the latter approach. And my
> > motivation is that, whenever possible, it is nice to separate
> > functionality from communication. Of course, this cannot hold for the
> > middleware components, whose functionality _is_ communication :-)
>
> Unfortunately Anthony says that codels are code supplied by the user. Under
> those circumstances communication would have to be located in the software
> framework (cold spots). Nevertheless we could also investigate codels
> treated as atomic library entieties from which the user constructs his/her
> user task of the component. In such a situation you could have communication
> codels. They would be delivered by the designers of the system (framework)
> designers (i.e. us).

I am in favour of your suggestion: there are user codels and developer
codel. Of course, the details are not all quite clear to me at this
moment, but I guess we will get there `Real Soon Now' :-)

Cezary, I hope you will be able to attend the Orocos meeting in Pisa?
There, we should define the final design and implementation road for
version 1.0 of the core components of Orocos...

Herman