Re: ipc.pdf ... some remarks

On Thu, 20 Jun 2002, Christian Schlegel wrote:

[...]
> > I describe a lower-level implementation, that should be compatible
> > with _any_ IPC. (If that is not the case, then something is wrong :-))
> > And the goal is to maybe come to a core library that many other Orocos
> > libraries could use...
> 
> Ok, but at this level it might be interesting to check if there are any parts
> which are not compatible with middleware like CORBA. If yes, that is an
> important topic to talk about ...

I _think_ nothing is incompatible with CORBA. How could it?

[...]
> Ok, mechanism and policy are sometimes difficult to differentiate since I do
> not want to implement all kinds of mechanisms which might be needed but are
> not yet needed. So sometimes the tradeoff is to implement only those
> mechanisms which are needed for a specific policy. 

Indeed! That's what I say in the text also. And this was exactly my
motivation: find the minimum set of mechanisms that _all_ Orocos
components need. And if we can implement this set in the Core (as
Peter and Takis are doing now), it could help the project a lot as far
as code and documentation reuse is concerned :-)

> But of course the overall
> mechanisms should fit together in a coherent way.

Exactly. And this coherence can only come from looking at the
mechanisms of different Orocos components from distance. And by
somebody who is not too involved in all the particular components. And
I think that's me :-)

[...]
> > Can you give an example of where you need a guard?
> 
> Very simple example: An event pattern is used to report on the battery
> voltage. Therefore the producer of the event reads the battery voltage
> regularly and has to decide when to fire the event. It now might have various
> components which have to be notified on specific voltage levels. Activating
> the event from the consumer includes the voltage threshold. 

Ok, good example! This `guard' doesn't leave the event mediator, so I
don't have a problem with that. I even think this is not a guard, but
part of the listener that the event consumers have registered with the
event object. Another approach is that the component that is
responsible for the battery has a method that others can use to fire
an event under specific battery load conditions.

I'll discuss this example with Takis and Peter...

[...]
> > interesting for the public.... Let me know if you don't mind if I post
> > these messages to the list.
> 
> Yes, you can post it ....

Fine :-)

Herman