You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.se> on 2006/05/05 10:58:38 UTC
Re[2]: [jira] Created: (FELIX-68) UPnP and Event Admin
During the specification of the Event Admin we had some discussions
about this. I recall that we did not want to specify who was bridging
the events. The natural solution is that each subsystem (like UPnP)
sends out the events to the event admin. This is in line with the way
we are going with new specs, they usually do not have their own
listeners anymore.
However, this leaves legacy code. In our reference implementation we
added mappers to Event Admin so we could minimize the work on the
older reference implementations. Obviously the huge disadvantage is
that Event Admin becomes coupled to everything which creates a Devil's
snare that you will get entangled in. This is therefore not the road
I'd like to go.
So for now, the best solution is to make each mapper a separate bundle. This is
a bit of extra work, but then the deployer can on a case by case basis
decide if a specific subsystem needs an event mapper.
In the future, the intention is that the subsystems (like UPnP)
deliver the events to Event Admin themselves.
So the spec does not define this case because we wanted it to leave
open. However, it would be nice if we had said we left it open and
showed the possibilities, sorry.
Kind regards,
Peter Kriens
>> > 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.
KP> But how does this change things in this regard? The spec clearly
KP> states that in R4 UPnPEvents must be available through the EA. It,
KP> however, fails to mention who is responsible to do this. Moreover, it
KP> is not exactly a legacy problem (it is now, but only because the R4
KP> spec is vague) - all that would have been necessary to avoid it would
KP> 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 ;-)
KP> Sure, that was my intention. I do the same with for example the
KP> adaption of LogService entries to events. There is no hard dependency
KP> on a LogService nor on the org.osgi.service.log package. As soon as a
KP> LogService becomes available its entries are adapted until it goes
KP> 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 ?
KP> Yes, as I was saying, that is the reason why I find it a good idea to
KP> put the UPnPEvent adaption in the EA too. As stated above, the EA has
KP> a dynamic import header for the org.osgi.service.log package and
KP> registers a service listener for LogReaders. As soon as such a service
KP> becomes available adaption is started for it until the service goes
KP> away. That way the EA has no hard dependency on any other bundle.
>> Didier
KP> O.k., let me propose the following, I integrate the bridge in the EA
KP> and make it a configurable option. That way we provide the possibility
KP> to adapt all UPnPEvents in case
KP> org.apache.felix.eventadmin.AdaptUPnPEvents=true
KP> if not then we don't. Additionally, I will ask at the osgi-dev list
KP> whether there is any better approach we didn't see.
KP> Opinions?
KP> regards,
KP> Karl
KP> --
KP> Karl Pauls
KP> karlpauls@gmail.com
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Karl Pauls wrote:
>> Didier will need to submit an ICLA first, unless the contribution is
>> really simple (I think).
>
> The contribution is really simple. It's what I've already attached
> plus an Activator. If this doesn't count as a patch then i don't now
> what does.
>
> A JIRA attachment marked as contribution should be all that is needed,
> otherwise I'll just use the code I've already attached. We would need
> a vote otherwise, don't we?
If it simple, great. I am not sure what the dividing line is, but when
it doubt ask for ICLAs and votes. :-)
-> richard
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Karl Pauls <ka...@gmail.com>.
> Didier will need to submit an ICLA first, unless the contribution is
> really simple (I think).
The contribution is really simple. It's what I've already attached
plus an Activator. If this doesn't count as a patch then i don't now
what does.
A JIRA attachment marked as contribution should be all that is needed,
otherwise I'll just use the code I've already attached. We would need
a vote otherwise, don't we?
> -> richard
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Karl Pauls wrote:
> I guess this counts as an official answer :-). I'll add a new bundle
> then that takes care of the adoption. Instead of using Rick's proposed
> property naming we could go with it as a bundle naming i.e.,
>
> trunk/
> org.apache.felix.eventadmin.bridge.upnp
>
> Objections?
Seems reasonable to me.
> p.s.: Didier, in case you still like to contribute your
> implementation, could you please attach it to the JIRA (marked as a
> contribution)? I'll pick it up there and use it as a starting point.
Didier will need to submit an ICLA first, unless the contribution is
really simple (I think).
-> richard
Re: Re[2]: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Karl Pauls <ka...@gmail.com>.
> So for now, the best solution is to make each mapper a separate bundle. This is
> a bit of extra work, but then the deployer can on a case by case basis
> decide if a specific subsystem needs an event mapper.
I guess this counts as an official answer :-). I'll add a new bundle
then that takes care of the adoption. Instead of using Rick's proposed
property naming we could go with it as a bundle naming i.e.,
trunk/
org.apache.felix.eventadmin.bridge.upnp
Objections?
regards,
Karl
p.s.: Didier, in case you still like to contribute your
implementation, could you please attach it to the JIRA (marked as a
contribution)? I'll pick it up there and use it as a starting point.
> In the future, the intention is that the subsystems (like UPnP)
> deliver the events to Event Admin themselves.
>
> So the spec does not define this case because we wanted it to leave
> open. However, it would be nice if we had said we left it open and
> showed the possibilities, sorry.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
>
> >> > 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.
>
> KP> But how does this change things in this regard? The spec clearly
> KP> states that in R4 UPnPEvents must be available through the EA. It,
> KP> however, fails to mention who is responsible to do this. Moreover, it
> KP> is not exactly a legacy problem (it is now, but only because the R4
> KP> spec is vague) - all that would have been necessary to avoid it would
> KP> 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 ;-)
>
> KP> Sure, that was my intention. I do the same with for example the
> KP> adaption of LogService entries to events. There is no hard dependency
> KP> on a LogService nor on the org.osgi.service.log package. As soon as a
> KP> LogService becomes available its entries are adapted until it goes
> KP> 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 ?
>
> KP> Yes, as I was saying, that is the reason why I find it a good idea to
> KP> put the UPnPEvent adaption in the EA too. As stated above, the EA has
> KP> a dynamic import header for the org.osgi.service.log package and
> KP> registers a service listener for LogReaders. As soon as such a service
> KP> becomes available adaption is started for it until the service goes
> KP> away. That way the EA has no hard dependency on any other bundle.
>
> >> Didier
>
> KP> O.k., let me propose the following, I integrate the bridge in the EA
> KP> and make it a configurable option. That way we provide the possibility
> KP> to adapt all UPnPEvents in case
>
> KP> org.apache.felix.eventadmin.AdaptUPnPEvents=true
>
> KP> if not then we don't. Additionally, I will ask at the osgi-dev list
> KP> whether there is any better approach we didn't see.
>
> KP> Opinions?
>
> KP> regards,
>
> KP> Karl
>
> KP> --
> KP> Karl Pauls
> KP> karlpauls@gmail.com
>
>
> --
> Peter Kriens Tel +33467542167
> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
> 34160 Beaulieu, France ICQ 255570717
> Skype pkriens Fax +1 8153772599
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Peter Kriens wrote:
> During the specification of the Event Admin we had some discussions
> about this. I recall that we did not want to specify who was bridging
> the events. The natural solution is that each subsystem (like UPnP)
> sends out the events to the event admin. This is in line with the way
> we are going with new specs, they usually do not have their own
> listeners anymore.
>
> However, this leaves legacy code. In our reference implementation we
> added mappers to Event Admin so we could minimize the work on the
> older reference implementations. Obviously the huge disadvantage is
> that Event Admin becomes coupled to everything which creates a Devil's
> snare that you will get entangled in. This is therefore not the road
> I'd like to go.
>
> So for now, the best solution is to make each mapper a separate bundle. This is
> a bit of extra work, but then the deployer can on a case by case basis
> decide if a specific subsystem needs an event mapper.
>
> In the future, the intention is that the subsystems (like UPnP)
> deliver the events to Event Admin themselves.
>
>
When you talk about UPnP Subsystem you refer to both the Base Driver and
UPnPDevice (imported and exported) , don't?
I like your previous proposal, but I think it will be (would had to be)
a definitive solution if we want to maintain compatibility with
UPnPDevice (OSGi side) already developed and coming ones.
Best regards,
francesco
> So the spec does not define this case because we wanted it to leave
> open. However, it would be nice if we had said we left it open and
> showed the possibilities, sorry.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
>
>
>>>> 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.
>>>
>
> KP> But how does this change things in this regard? The spec clearly
> KP> states that in R4 UPnPEvents must be available through the EA. It,
> KP> however, fails to mention who is responsible to do this. Moreover, it
> KP> is not exactly a legacy problem (it is now, but only because the R4
> KP> spec is vague) - all that would have been necessary to avoid it would
> KP> 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 ;-)
>>>
>
> KP> Sure, that was my intention. I do the same with for example the
> KP> adaption of LogService entries to events. There is no hard dependency
> KP> on a LogService nor on the org.osgi.service.log package. As soon as a
> KP> LogService becomes available its entries are adapted until it goes
> KP> 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 ?
>>>
>
> KP> Yes, as I was saying, that is the reason why I find it a good idea to
> KP> put the UPnPEvent adaption in the EA too. As stated above, the EA has
> KP> a dynamic import header for the org.osgi.service.log package and
> KP> registers a service listener for LogReaders. As soon as such a service
> KP> becomes available adaption is started for it until the service goes
> KP> away. That way the EA has no hard dependency on any other bundle.
>
>
>>> Didier
>>>
>
> KP> O.k., let me propose the following, I integrate the bridge in the EA
> KP> and make it a configurable option. That way we provide the possibility
> KP> to adapt all UPnPEvents in case
>
> KP> org.apache.felix.eventadmin.AdaptUPnPEvents=true
>
> KP> if not then we don't. Additionally, I will ask at the osgi-dev list
> KP> whether there is any better approach we didn't see.
>
> KP> Opinions?
>
> KP> regards,
>
> KP> Karl
>
> KP> --
> KP> Karl Pauls
> KP> karlpauls@gmail.com
>
>
>