Karl Pauls wrote:
Francesco, you are right. The intention was to make a start - maybe I
should have made that more clear.
ok, I didn't get it .
but you are still registering an UPnPEventListener with a NULL filter
thus *all* UPnP devices will start to send upnpEventNotify messages to
the Bridge .... the same drawbacks for the network
That is not true in general, because now the UPnPEventListener is
registered only in case at least one EventAdmin and at least on
(applicable) EventHandler is present. Granted, once theses conditions
are met, it is registered with a NULL filter.
that's true
You could also registering only an instance of UPnPEventListener but you
should to update its filter every time a new EventHandler is registered
or modified.
That was the ultimate goal. I'm still working on that part.
take your time
In any case you should always
create a new UPnPeventListener if there are subscriber that want to
receive events from all the devices ( they would register an handler
with NULL filter).
Given the one UPnPEventListener with an ever updating "concatenated"
filter why would I ever want to register a "new" UPnPEventListener.
Isn't it sufficient to set the filter to null on the original one
(whenever at least one EventHandler is interested on all events)?
well, effectively if you want to use the same listener you could clear
the filter and save the old one in the case the "NULL" subscriber is
removed.
You should anyway update any change in the filters of the other
handlers or rebuild it when the "NULL" handler is removed.
Using a secondary UPnPListener seems to me more simply ....
Following up the previous discussion concerning postEvent or a direct
call to the eventHandle, consider that the UPnP spec already states
that the uppnpEventNotify messages must be sent asynchronously so should
be enough safe (uhu aha :-) ) to call directly the eventHandle ...
Well, as I mentioned in my reply to Stefano, there is a bit more that
it would need to do. Specifically, it would need to check that the
EventHandler has the appropriate permissions to receive the event.
Useful to know, however, that the UPnPEventListener is called
asynchronously already.
Ok I trust you because I don't know EA details deeply ;-) ... thanks
Stefano too
ciao
francesco
Give me a bit more time to give the "one UPnPEventListener with an
ever updating concatenating filter" approach a shot. In case that
won't fix it, I'm open to try different approaches.
Some consideration to help you in this concern.
Doing a mapping 1:1 between handlers and listeners is simple and, most
importantly, you delegate the responsibility about the threading and the
secure event copy to the event source, namely UPnPDevices and Base
Driver. Here the goal is to provide a wrapper of UPnPEventListener to
EventHandler users.
Doing a n:1 mapping you effectively go to play with EA role and
potentially you can do some optimizations. But you have to face the
threading, hence postEvent is obviously the best solution to avoid
duplication of code, but you fail with the secure event copy because EA
don't know nothing about UPnP events and there isn't a clear contract
about mutable properties in the spec :(
regards,
francesco
