Re: A working document

> On Fri, 21 Dec 2001, Cezary Zielinski wrote:
>
> [...]
>
> > 4) I would suggest a change in terminology. Instead of using the
> > term "database" I would use the term "component image". Database has
> > a slightly different meaning in computer science. In this case the
> > outside world (other components) percive the component through the
> > exported image. This compnent perceives other components through
> > imported image. Thus we have a component image.
>
> I like this statement. Do you have any links to published computer
> science literature where this concept of ``component image'' is
> documented?
>

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. Unfortunately from what Anthony wrote his databases are not visible
from outside. Only the information exported from the database is seen
outside. Thus only this information could be called an image of the
component. That is OK to call it that, but that still leaves us with the
name database to which I objected.

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

Cezary


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