[Embedlets-dev] Re: Event Manager

[Andrzej J. T. <an...@ch...>]

Gregg suggests:

> We wanted to do all of these, and Jini LUS users want all of these.  But
> in the end, it is simpler to limit the criteria.  For pub/sub, I'd still
> suggest a simple hierachial topic string system, and that you should just
> include the appropriate parts in the topics.  Predefined topic trees would
> be beneficial, but using properties to configure modules to use the
> appropriate topic simplifies the whole mess by delaying this issue till
> deployment which can allow some modules to be used in ways that were not
> originally in the design.
> 
> control.switch.off.1.<producer>
> 
> is an example topic, where everything is specified.  In a topic system, at
> deployment time, you could match with
> 
> control.switch.*.1.*

I like it.  It's a nice way to keep things simple, provides some 
optimization opportunities along the way, and gives the developers a very 
extensible event typing/matching system that should be more than enough 
for their needs in the embedded space.  Unless anyone has any objections 
(or better suggestions), I'll structure the Event Manager Service 
specifications along these lines.

The only thing I think I would do differently is to keep the <producers> 
and/or <consumer> critera out of the topic string, since this would allow 
for much more efficient filtering on the part of the Event Manager 
without adding much in the way of complexity for the developer. 
Conceptually, it also keeps things a touch clearer since who produced (or 
should be allowed to consume an event) is not really part of the event 
type (or topic).

> I do have a broadcast 'space' that includes single copy delivery in a mesh
> environment, and topic based pub/sub, that I am willing to 'donate' to the
> cause...

Is this a JINI space?

...Andrzej

Chaeron Corporation
http://www.chaeron.com