Re: ipc.pdf ... some remarks

On Thu, 20 Jun 2002, Christian Schlegel wrote:

> Herman Bruyninckx wrote:
> 
> > On Thu, 20 Jun 2002, Christian Schlegel wrote:
> >
> > [...guard in battery-level event...]
> >
> > > The question is what has to be transmitted to consumers. If I have
> > > the check for the event condition at the producer I do not have to
> > > transmit anything to the consumer (sometimes it is not only the
> > > battery voltage but an image e.g.). An important reason why I want
> > > to have the event check at the producer is because I have access to
> > > several producer internal states which I can collect in case the
> > > event fires. I can report a complete state to the consumer.
> >
> > That is exactly what we want to avoid: reporting to the consumer about
> > an internal state of the producer...
> 
> Be careful to get it right ! I don't want to report states to consumers
> which are of no meaning there because the context is missing. But think of
> an event where you have seen an object during moving around. You want to
> report the complete state in the sense that you know where that object is
> (image, pose of the camera including current pan-tilt-unit settings and
> robot pose). Ok, not an excellent example but you know what I mean. 

I think it _is_ a good and relevant example, but the difference with
what I want to express is that in your example, this `state' belongs
to the interface of the `tracking component' (or whatever), and hence
it is ok (and necessary) to export this data. In the battery low
example, I don't see a reason why to export the information about a
certain battery level to more than the clients that want to be
notified about that fact. Maybe I jumped to conclusions, and your
implementation doesn't do this...


> In many
> cases you not only want to report there is an event but also what caused
> the event and that data is available at the producer. 
Exactly. And every time you say ``in many cases...'' I respond: ``this
is the _policy_ of the components that manages a certain resource, but
it is not mechanism of the drivers which the managing component needs
to get at its information.'' 

I think it is time we stop this discussion about the sex of the
angles, and decide whenever a particular angle is committed to the CVS :-)

[...]
> Look at my document where I describe my events. All consumers activate the
> event with their parameters. As soon as you have new data at the producer
> (you have read the battery voltage) you check all your activations and
> decide depending on the individual parameters whether to fire or not. 

But _what_ do you fire? An event that carries the data that caused the
event? In that case you notify too many clients. I fail to see how
sending the data along and let the consumer decide _after_ the facts,
is better than letting the consumers decide _at registration time_
what events they want to get.

> The patterns make sure that you
> only get YOUR activation reported and that you don't have the problem of
> getting messed up with events which are not of any meaning for you ! 

I suspect that you reach the same (laudible) goal in a ``wrong way,''
i.e., by exporting the state of the battery component to its event
object. But again, I might be wrong in my suspicions :-)


> What I
> have at the producer side is an event condition parameterized by the
> individual activation parameters (and therefore it looks like a guard for
> the event activation, I always used "method to check event condition").

This, in my view, belongs to the device component guarding the
battery, not to its event object.

> Therefore: battery component provides an event which takes parameters on
> the voltage level and wether I want to be informed in case of falling below
> or getting above or both etc. 

I would send the former data also, but not the latter decision information.
This decision must be made by the consumer, at registration time.

> (see my remarks on different kinds of event,
> with state and without state: corresponds to state versus edge triggered).

This is an interesting discussion in itself: where do we need edge
triggering and where level triggering...? Or rather, where do we have
to export this information?

> If consumer A activates the event with "below 10%" it gets his activation
> fired as soon as his event condition is true. The producer only puts in the
> battery voltage and the producer part of the event does everything else.
> The implementer of the battery event simply provides the method for the
> condition check. 

I have the impression that you have to evaluate the condition twice:
once in the battery component (otherwise, it will not generate an
event), and once in the event handler?

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480