There is another problem due to the asymmetry of the EA API, that is the
subscription is for all the EAs while the publishing is for a specific EA.
The client interested to some UPnP events registers an EventHandler with
the framework. If we have multiple EA installed, they all monitor the
handlers and will receive a postEvent Message from the bridge.
In that's way for each UPnP events (UPnPEventNotify) received by the
Bridge we duplicate the event posting the message to every EA service.
Hence the client will receive many copies of the message depending from
the number of EA installed.
The solution with direct dispatching overcomes this problem.
Of course you could to select just the first EA (switching to the
others as soon as it is unisinstalled) mmmm :)
>
> 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.
Is not clear to me whether the Felix Bridge is thought as universal
bridge (for all the EA implemenations), or every EA service will install
its upnp bridge. What do you have in mind?
Should even this aspect clarified by the specification?
francesco.
Karl Pauls wrote:
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
covered.
regards,
Karl
