Karl Pauls wrote:
> Hm, the problem I see with this is how do you know that a device that
> reads the spec differently doesn't send its events to the event admin
> too? Then we end-up with a situation where we have duplicated events.
>
Sure, but this is legacy since the
org.osgi.service.upnp.UPnPEventListener exists before R4 and EventAdmin.
But how does this change things in this regard? The spec clearly
states that in R4 UPnPEvents must be available through the EA. It,
however, fails to mention who is responsible to do this. Moreover, it
is not exactly a legacy problem (it is now, but only because the R4
spec is vague) - all that would have been necessary to avoid it would
have been to be specific about who is doing the adaption.
One more thing : an argument to add the UPnP to EA bridge inside the EA
implementation may be an optimization
in which the bridge is deactived when non EventHandler with
(event.topics=org/osgi/service/upnp/UPnPEvent) is registered !
A general-purpose dependency manager could be useful in this context !
Isn't it Rick ;-)
Sure, that was my intention. I do the same with for example the
adaption of LogService entries to events. There is no hard dependency
on a LogService nor on the org.osgi.service.log package. As soon as a
LogService becomes available its entries are adapted until it goes
away again.
More over, there is the same optimization for Framework-,
Bundle-,Service-, and Log-Events
Karl, how do you tacckle that in your EA implementation ?
Yes, as I was saying, that is the reason why I find it a good idea to
put the UPnPEvent adaption in the EA too. As stated above, the EA has
a dynamic import header for the org.osgi.service.log package and
registers a service listener for LogReaders. As soon as such a service
becomes available adaption is started for it until the service goes
away. That way the EA has no hard dependency on any other bundle.
Didier
O.k., let me propose the following, I integrate the bridge in the EA
and make it a configurable option. That way we provide the possibility
to adapt all UPnPEvents in case
org.apache.felix.eventadmin.AdaptUPnPEvents=true
if not then we don't. Additionally, I will ask at the osgi-dev list
whether there is any better approach we didn't see.
Opinions?
excellent for me, it goes in the direction to simplify the coding for
the developers too.
If we interpreter the new specification literally and taking into
account the old one, the only solution I see is the following:
1) the Base Driver dispatches only the events coming from imported
devices to every EA service if available (physical devices on the UPnP
network).
2) every UPnPDevice dispatches the generated events to every EA service
if available.
I'll commit in my sandbox the DomowareUtil classes that Didier already
knows that can come in help to the UPnPDevice developers, we could
modify them in order to consider the dispatching to the EA services.
But It seems me that moving the dispatching to the EA service is a more
simple approach, consider that the UPnP Tester bundle already works in
this way, and the cost to register a general UPnPEventLister is
negligible in comparison to the "litterally" solution when we consider
the complication we avoid to the developers.
We have absolutely receive an official clarification from OSGi
otherwise we risk to have two different solutions to the problem.
One more thing, the Tester bundle if you like could be user in more
general way to monitor not only UPnP Events but also the state of the EA
Service .... just a thought on which we can return to discuss ...;-)
Francesco
regards,
Karl
--
Karl Pauls
[EMAIL PROTECTED]
