Karl Pauls wrote:
> Hi Francesco,
>
> l see your point and I think it is very important to fix the
> situation. I agree with parts of your proposal but I don't understand
> why you don't want to use the EventAdmin itself.
> As far as I can see your problem is not related to the EventAdmin
> being used for the dispatch but only with registering an unbounded
> UPnPEventListener.
>
> I think we should stick with the first part of your proposal namely,
> registering UPnPEventListeners only in the case a matching
> EventHandler is in place. The second part (that the Adapter would be
> responsible to dispatch the events too) would effectively lead to the
> Adapter becoming a specialized EventAdmin itself. That is not needed
> (unless I'm missing something).
Hi Karl,
I have spoken face to face with Francesco I understood that he don't
want to create a new EventAdmin but just a bundle that act like and
EventAdmin. Let me clarify that.
The Event Admin(EA) is used to split Event Publisher(EP) from Event
Handler(EH), so it's duty of EA to discover which EH receive a Event
every time EP send an Event. So the EP won't even know who and if
someone have handled the Event.
In our case the situation is quite different, in fact to avoid the
overload off UPnP Network we set up a EP only when EH are present so our
Bridge will need the code that handle such things.
So because we have the code that track EH we can even avoid to go
thought the EA for sending the event.
Before say that's not correct please notice that this behavior even if
it's not the one aspect by OSGi Analyst is not out of spec and also
we'll avoid the duplication the execution of code that track EH. BTW, I
know that such implementation may be not clear to understood at the
beginning.
Finally, that's the way Francesco thought about "distributed EA"
Stefano "Kismet" Lenzi
P.S.: The only extra code need will be a tracking of EA because when
none are present on OSGi our bridge must stop to send Event to EH
>
> regards,
>
> Karl
>
