Re: A working document

> [... proxy vs interface ...]
> > A proxy is a stand-in who acts in the name of someone. The image is
> > simply a data structure representing some properties of the
> > component B. An image is passive, a proxy is active. I think that I
> > would rather prefer "interface" than "proxy" in our case, although
> > both don't suit me.
>
> A proxy represents an object/component, whether or not it is active.
> And I don't think it is a good idea to let component A have an
> `internal image' of component B: this introduces too much coupling
> between both components! (Duplicating the `stte' of an component
> somewhere in another component leads to untractable maintenance
> problems sooner or later...)
>

I fully agree that this can cause problems. Nevertheless you have to create
images for computational reasons. Example. Let EDP (Effector Driver Process)
be responsible for execution of a single motion step of a manipulator arm
(it is responsible for direct communication with the hardware). Let ECP
(Effector Control Process) be responsible for the execution of a whole
trajectory of the arm. To compute this trajectory (e.g. interpolation from
the current position to the target position) ECP needs the current stste
(i.e. position) of the arm. That will be included in the effector image
stored in ECP, but obtained from EDP. EDP will have to have an image of a
portion (1 step) of the trajectory created by the ECP to execute the motion.
Those images will be updated during communication between EDP and ECP. It is
up to the programmer to assure that both processes operate on valid data. In
MRROC++ images are updated at a certain rate that is equivalent to sampling
rate or a small multiple of that.

In general I think it is impossible to design a fail-safe system when
delivering just the building blocks and a general framework. You simply
cannot prevent someone from misusing the delivered components. Only closed
systems can be safe in that respect (and even those usually are not).

I thought a bit more about the differences between interfaces, proxies and
images. This is what I came up with.
If we have two components A and B there are (among others) the following
possibilities.
1) The interface of component A is located in component A and is the
representation of this component to the outside world.
2) The components A and B communicate with one another not directly but
through a go-between - a proxy which can be named component C.
3) The actions of component B depend on the current state of component A.
For computational reasons an image of A has to be formed in B. This image is
updated either by using the interface of A or through a proxy C or by some
other means.
I hope that shows how I think about the relationship between those three
terms.

Nevertheless you have brought up a very important problem of how to keep the
contents of the image always valid. In MRROC++ it is a partial
responsibility of the programmer. Partial, because there are library
mechanisms (codels?) that update the images. Unfortunately there is nothing
to prevent the programmer from not using them and writing some C++ code of
his own instead and thus crashing the system. Well, if you have a very
flexible tool and don't use it cautiously you are bound to harm yourself -
this is an unfortunate twist of life ;-(. Still think that we could come up
with something better in OROCOS.

Cezary

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