felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: Again on the UPnP and Event Admin service
Date Wed, 21 Jun 2006 10:35:43 GMT
> So taking in mind the stack of all calls among the UPnP devices and the
> final consumers, I simply thought that we could avoid to involve the
> Event Admin again.

There is no problem with involving the EventAdmin. That is what is in
the spec and why we created the bridge in the first place.

> If we continue to adopt a bridge architecture, in the
> case we decide to use postEvent message, we have both the Bridge and the
> EA monitoring the same EventHandlers.

True. This clearly is an optimization for this special case namely, to
ease network load pain.

> I haven't make a cost evaluation of all it, but if you think it has a small impact on
the EA > and the runtime we could use these indirection.

Basically, all that it takes is one more ServiceEventHandler. There is
no noticeable impact whatsoever.

> I mean the Bridge is needed only to achieve the point 113.1.1 just for
> uniformity and if we adopt a "ad hoc" solution (without posting to the
> EA)  we don't break the general design.

In my opinion you don't gain anything with this. In fact, quite the
opposite, your are creating yet another EventAdmin that will have to
run in parallel with a "normal" one.

It is true that this wouldn't break the design as such - nevertheless,
it be a duplication of efforts (both, in terms of runtime and code).

> Consider also that we are talking about an unusual way of using the EA
> service. It should be "agnostic", a data producer should put the events
> on the whiteboard and a data consumer should get them without any
> intervention of the EA. In UPnP case the EA is supposed to have some
> knowledge about the events it are managing, otherwise no data consumers
> would be activated.
> For these reasons I was thinking to the bridge as a special case.

I understand where you are coming from; it nevertheless stands to
reason that if someone decided to use the EventAdmin to receive
UPnPEvents she specifically asks for the EventAdmin semantics.
Otherwise, she would have used the UPnPEventHandler approach.

As you pointed out the EventAdmin approach and the UPnPEventHandler
approach are in conflict to some degree (i.e., the network load issue)
but that is why we now have aforementioned two level of degradation:
don't install the bridge and only bridge in case of interest.

> regards,
> francesco

In summary, yes, there is a difference between the EventAdmin approach
and the UPnPEventHandler approach due to the former assuming a push
based model while the later apparently targeting a pull based scenario
in order to ease network load. They don't play along too well together
but I think with a separate bundle for the bridge plus the bundle only
registering an UPnPEventHandler in case at least one EventAdmin and at
least one interested EventHandler is present we should have our bases


Karl Pauls

View raw message