Karl Pauls wrote:
Hi Francesco,
The specification doesn't tell explicitly that the Base Driver has to
act as bridge
towards the Event Admin, but it simply states that UPnP events has to
delivered to
the EA service.
I guess the information I'm looking for is: Who is doing the UPnP
event dispatching? Is this something that is part of the base driver?
Indeed the event dispatching is distributed. If you register a
UPnPDevice without the UPNP_EXPORT property the device will be discarded
by the Base Driver and it doen't create a proxy UPnP-Device on the UPnP
network. But the UPnPDevice is a valid device that will generate UPnP
Events on the OSGi side that other UPnPDevice can listen.
For instance , try to run the Base Driver, the Tester, the TV and the
Clock example.
The Tester will show the devices and the time is updated every second on
the TV. If you stop the Base Driver the devices will continue to work
because the event dispatching is responsibility of the single device
that generates the event. Also the Tester will continue to work and you
can also invoke actions on the local UPnP devices.
Generally for each exported device the Base Driver relies on the
UPnPEventListener interface to be notified of the changes and use the
parameters of UPnPEventNotify() to modify the state of the correspondent
proxy on the UPnP Network.
That is because I said that the specification seems to me a bit elusive
referring to UPnP Events ...
Moreover this could be a valid reason to adopt an external bundle that
bridge all the UPnP Events to the EA service ... it works also without
the base driver ....
Of course we can also modify the normal behavior of the Base Driver in
order to monitor also the UN-EXPORTED device.... BTW if the Base Driver
is stopped (and theexternal bundle too) there isn't a way to communicate
the UPnP Events to the EA service. It should be responsibility of the
device ....
Another question is about the the consumers of the UPnP Events, from the
point of view of OSGi-UPnP developers the writing of
UPnPEventListeners or EventHandler is equivalent, it doesn't
simplify the coding, but the EA service is not always available ( not
being in the core specification)
As far as I know that is not the point. The idea about the event admin
is that bundles that are interested in all sorts of events (e.g.,
FrameworkEvent, ServiceEvent, LogServiceEvent, UPnPEvent) have a
central and unified way to subscribe to events of interest.
That means that in the future we will change the
communication mechanism? I have noticed that also the framework topics
have been defined ...
Again, it probably is more interesting for bundles that need to know
about more than just one specific event type. In this case all they
need to do is register an event handler for the event admin events and
not N handlers for N different event systems. The only place where it
is more preferable to not use this approach is where they only need to
know about a single specific event.
Regarding the use of a separate bundle registering a generic
UPnPEventListener, I would be attempt to use this solution, putting all
in the Extra bundle, but it results in extra messages exchanged, while
doing that in the Base Driver we should only to modify the code to add
the posting of the messages....
Exactly, (due to the spec) I wouldn't expect to have to install a
separate bundle just to get this functionality. Furthermore, In the
version I've attached to the JIRA no hard dependency on the
org.osgi.service.event package or the EventAdmin service is created.
Combined with a dynamic import events will be delivered only in the
case that an event admin is present.
regards
francesco
In summary, I believe the best route would be to integrate the
UPnPEventToEventAdminBridge into the UPnP core - provided that this is
where the actual event dispatch is taking place. Otherwise, you'll
need to educate me further (or I have to go back and read the spec in
detail).
It boils down (unless I'm missing something) to a simple:
UPnPEventHandlerQueue.add(new UPnPEventToEventAdminBridge(context))
As I explained there isn't a central point for dispatching the events in
the Base Driver ...
The adoption of this solution is similar to the external bundle you have
to register a UPnPListener.... if we modify the Base driver then we
have just to post the events to the EA service .... Anyway I like your
solution ( and Didier' equivalent) because it is compact ...
I just don't know where this needs to be done.
regards,
Karl
--
Karl Pauls
[EMAIL PROTECTED]
