Events

[Harald Scheirich]

During the recent development on the Burrhole simulator, we have come to see the need to notify other components of events inside the system. In the case of the burrhole it was with the introduction of the CountDownBehavior user interaction in which we need to know when the user has started and if the user has aborted or finished the interaction. 

The current paradigm is to query for rather rather than to be notified of state changes, that works reasonably well for numerical state, but in some cases the information that is important is not so much the actual state or value but the change of that value. For example in the case of the countdown display the time that the user started interaction, and the fact that the user sucessfully interacted (i.e. they waited for three seconds inside the collision area). For the CountownBehavior the events are 'Started', 'Aborted', and 'Finished'.

There are two questions, should OSS support events at all, the above example could probably be rewritten for a stateless approach e.g. isInteracting(), lastSuccess(). I think for this question the answer is yes, in a lot of cases we can probably just reduce effort by moving from querying to events. 

If we do want to support events, how can we do that in a consistent manner. A few approaches come to mind, the CountDownBehavior currently uses delegation(callbacks) via an abstract class that defines its interface (CountDownCallback). This works, but might lead to an accumulation of abstract interfaces. A similar approach would let interested parties register single callback functions, similar to what is being done in the plyreader delegate. Both of these solutions would be very specific to each publisher of events. 

A more general solution would be to implement a generic Publish/Subscribe on the component or the behavior level, where publishers use component infrastructure to post events and subscribers get notified through that component infrastructure. An event might not be more than a pair of event name and sender. I think I would probably prefer this approach, as it will have the highest reuse value.

As I said we already need this in Burrhole, besides the user interaction this will be needed to indicate the start of drilling to a possible larger number of components, or to indicate other states like the loss of head tracking. A general approach might help further decouple components.

Thanks, Harry 

--

Harald Scheirich

Principal Software Engineer

Simquest Solutions Inc. 

hsche...@simquest.com

[Sebastian Ordas]

Dear Harald,

You may have a look at the State Machine design implemented in IGSTK (http://www.igstk.org/) and its underlying event-based state transition scheme: http://public.kitware.com/IGSTK/NightlyDoc/classigstk_1_1StateMachine.html.

Chapter 6 of the IGSTK Book (http://www.igstk.org/IGSTK/img/IGSTKTheBookV2.pdf) describes it very nicely.

Best regards,
sebastian

--
You received this message because you are subscribed to the Google Groups "openSurgSim" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensurgsim...@simquest.com.
To post to this group, send email to opens...@simquest.com.
Visit this group at http://groups.google.com/a/simquest.com/group/opensurgsim/.

[Paul Novotny]

Hi Sebastian,

Thanks for the reminder about IGSTK's state machines. I read the
documentation, and like how they coupled events and the state machine.
Making it easy for events to trigger state transitions. It was good to
read their motivation, and reasoning behind their design decisions. I
also like how the observer and events are decoupled from the classes
that use them, and doesn't require classes to be derived from a common
ancestor to pass events.

At the moment, we are investigating Boost's state machines and
implementation of signals and slots (Boost.Signals2). I think we will
take a lot of what IGSTK does into consideration.

-Paul

> > hsche...@simquest.com <mailto:hsche...@simquest.com>

> > --
> > You received this message because you are subscribed to the Google
> > Groups "openSurgSim" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to opensurgsim...@simquest.com

> > <mailto:opensurgsim...@simquest.com>.

> > To post to this group, send email to opens...@simquest.com

> > <mailto:opens...@simquest.com>.