Re: A working document

On Fri, 28 Dec 2001, Cezary Zielinski wrote:

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

That's exactly the reason why people have come up with the concept of
a proxy :-)

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

I agree on this approach; it's in our design too.

> 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 agree. We don't have the ambition to build a save framework. It
cannot be, by definition, because it doesn't fill in all ``hot
spots''.

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

This view is compatible with the ``broker'' software pattern, that
will be used in Orocos. Christensen's group will report on the broker
design.

So, after all, the orocos design is not revolutionary at all, because
it uses old Software Patterns, i.e., solutions that have been used
successfully in other systems already (such as yours, those in LAAS,
Christian Schlegel's SmartSoft, etc). I don't think this is bad :-)

Herman