You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Francesco Furfari (JIRA)" <ji...@apache.org> on 2006/05/03 10:55:46 UTC
[jira] Created: (FELIX-68)
UPnP Events and Event Admin service
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
UPnP Events and Event Admin service
--------------------------------------
Key: FELIX-68
URL: http://issues.apache.org/jira/browse/FELIX-68
Project: Felix
Type: Sub-task
Components: UPnP Device Service
Versions: 0.8.0
Reporter: Francesco Furfari
We have to integrate the Event Admin Service (see Karl Pauls implementation) as described in section 112.9 of UPnP Device Service Specification 1.1
The objective of this new feature is not so clear to me :( I think we have discuss a bit about it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
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
>
>
>
Re[2]: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Peter Kriens <Pe...@aQute.se>.
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 Francesco Furfari <fr...@isti.cnr.it>.
Karl Pauls wrote:
>> > O.k., let me propose the following, I integrate the bridge in the EA
>> > and make it a configurable option.
>
>> > 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.
>
> -- snip ---
>
>> 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.
>
> O.k., I'll assign the JIRA to me then an resolve it as soon as I find
> some time.
>
fine :-)
>> We have absolutely receive an official clarification from OSGi
>> otherwise we risk to have two different solutions to the problem.
>
> By making it an optional feature of the EA we at least don't make a
> mistake. Once I resolved the JIRA I'm going to ask at osgi-dev.
>
Ya, but I would prefer an official position because there are many
actors in play.
UPnPDevice developers, Base Driver implementations, EA implementations ....
I would like maintain interoperability among them, so don't hesitate to
post ASAP the question to OSGi-dev ML .... even before coding something
regards,
francesco
>> 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 ...;-)
>
> Yeah, that's a good idea. That way we could add something like a
> warning if events are not bridged and hint the user to enable the
> bridging in the EA.
>
>> Francesco
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Karl Pauls <ka...@gmail.com>.
> > O.k., let me propose the following, I integrate the bridge in the EA
> > and make it a configurable option.
> > 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.
-- snip ---
> 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.
O.k., I'll assign the JIRA to me then an resolve it as soon as I find some time.
> We have absolutely receive an official clarification from OSGi
> otherwise we risk to have two different solutions to the problem.
By making it an optional feature of the EA we at least don't make a
mistake. Once I resolved the JIRA I'm going to ask at osgi-dev.
> 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 ...;-)
Yeah, that's a good idea. That way we could add something like a
warning if events are not bridged and hint the user to enable the
bridging in the EA.
> Francesco
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Francesco Furfari <fr...@isti.cnr.it>.
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
> karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Karl Pauls wrote:
> 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?
Sounds reasonable to me, although I would change the property name to:
org.apache.felix.eventadmin.bridge.upnp
Then you can have other properties for other bridges, no?
-> richard
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Karl Pauls <ka...@gmail.com>.
> > 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?
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Didier Donsez <di...@imag.fr>.
Karl Pauls a écrit :
>> Indeed the event dispatching is distributed.
>
>
> o.k., I see.
>
>> 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 ....
>
>
> 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.
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 ;-)
More over, there is the same optimization for Framework-,
Bundle-,Service-, and Log-Events
Karl, how do you tacckle that in your EA implementation ?
Didier
> This sounds like a tough problem. If we provide an external bridge
> then we could create duplicated events - If we don't then for some
> events no bridging is taking place ... either way we lose :-(
>
> Maybe we should raise this issue on the osgi-dev list and request some
> clarifications on who is supposed to do what exactly?!
>
> Additionally, rather then creating a separate bundle, I'd propose to
> include the bridge in the EventAdmin instead. It already does some
> other bridging anyways (i.e., Framework-, Bundle-,Service-, and
> Log-Events). Does this sound like a good idea?
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
---------------------------------------------------------
Didier DONSEZ
Laboratoire LSR, Institut Imag, Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/~donsez
---------------------------------------------------------
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Karl Pauls <ka...@gmail.com>.
> Indeed the event dispatching is distributed.
o.k., I see.
> 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 ....
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.
This sounds like a tough problem. If we provide an external bridge
then we could create duplicated events - If we don't then for some
events no bridging is taking place ... either way we lose :-(
Maybe we should raise this issue on the osgi-dev list and request some
clarifications on who is supposed to do what exactly?!
Additionally, rather then creating a separate bundle, I'd propose to
include the bridge in the EventAdmin instead. It already does some
other bridging anyways (i.e., Framework-, Bundle-,Service-, and
Log-Events). Does this sound like a good idea?
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Francesco Furfari <fr...@isti.cnr.it>.
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
> karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Karl Pauls <ka...@gmail.com>.
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?
> 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))
I just don't know where this needs to be done.
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68) UPnP and Event Admin
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Hi Karl, Didier, all,
I'm back...well I have general (maybe trivial) questions about the
objectives pursued by the R4 designers. 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. Besides the Base Driver doesn't come in help of developing of
exported UPnPDevice, in fact developers have to manage the delivery of
UPnP Events alone . So developers could try to send their events to the
EA service too, contributing in a duplication of messages.
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) So I suspect that the mechanism based
on the service interface will be preferred to the second one. The
introduction of the Event Admin spec begins telling "So far, the
preferred mechanism to disperse those events have been the service
interface mechanism". That means that in the future we will change the
communication mechanism? I have noticed that also the framework topics
have been defined ...
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....
regards
francesco
Karl Pauls wrote:
>> I have done this event publisher long time ago (especially for
>> Francesco)
>> http://www-adele.imag.fr/~donsez/dev/osgi/upnpeventpublisher/
>
> I think the issue here is that its the responsibility of the UPnP
> implementation to provide the bridge. How I understand the spec it
> isn't necessary to wrap this in a separate bundle.
>
> But I could be wrong.
>
>> I can donate it to Felix
>
> As far as I can see, this is doing the same as the code I attached to
> the JIRA and we are talking about a 40 lines of code here... but
> still, why don't you attache it to the JIRA too?
>
>> Didier
>
> Additionally, I'd like to discuss whether it is a good idea to create
> a package dependency on the org.osgi.service.event package (only in
> case it is included into the UPnP implementation) .... The code I
> provided should work with a DynamicPackage-Import as well (whether or
> not this is a good thing is debatable :-)
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
Re: [jira] Created: (FELIX-68)
Posted by Karl Pauls <ka...@gmail.com>.
> I have done this event publisher long time ago (especially for Francesco)
> http://www-adele.imag.fr/~donsez/dev/osgi/upnpeventpublisher/
I think the issue here is that its the responsibility of the UPnP
implementation to provide the bridge. How I understand the spec it
isn't necessary to wrap this in a separate bundle.
But I could be wrong.
> I can donate it to Felix
As far as I can see, this is doing the same as the code I attached to
the JIRA and we are talking about a 40 lines of code here... but
still, why don't you attache it to the JIRA too?
> Didier
Additionally, I'd like to discuss whether it is a good idea to create
a package dependency on the org.osgi.service.event package (only in
case it is included into the UPnP implementation) .... The code I
provided should work with a DynamicPackage-Import as well (whether or
not this is a good thing is debatable :-)
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: [jira] Created: (FELIX-68)
Posted by Didier Donsez <di...@imag.fr>.
I have done this event publisher long time ago (especially for Francesco)
http://www-adele.imag.fr/~donsez/dev/osgi/upnpeventpublisher/
I can donate it to Felix
Remark: my University have already signed the "donation agreement" (I
can't remember the right term)
Didier
Karl Pauls a écrit :
> On 5/3/06, Francesco Furfari (JIRA) <ji...@apache.org> wrote:
>
>> UPnP Events and Event Admin service
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encoding: 7bit
>>
>>
>> UPnP Events and Event Admin service
>> --------------------------------------
>>
>> Key: FELIX-68
>> URL: http://issues.apache.org/jira/browse/FELIX-68
>> Project: Felix
>> Type: Sub-task
>>
>> Components: UPnP Device Service
>> Versions: 0.8.0
>> Reporter: Francesco Furfari
>>
>>
>> We have to integrate the Event Admin Service (see Karl Pauls
>> implementation) as
>> described in section 112.9 of UPnP Device Service Specification 1.1
>
>
> I've attached a starting point for a UPnPEventToEventAdminBridge to
> this issue. The comment, however, is only felix-developer readable -
> that is a mistake but it's not really important.
>
>> The objective of this new feature is not so clear to me :( I think
>> we have discuss a bit
>> about it.
>
>
> What exactly is it you want to discuss? I might be lagging a bit until
> Tuesday (due to some travelling).
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
---------------------------------------------------------
Didier DONSEZ
Laboratoire LSR, Institut Imag, Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
GPS : lat 45°11'38.3"N, lon 05°46'14.7"E, alt 223m
Tel : +33 4 76 63 55 49 Fax : +33 4 76 63 55 50
mailto:Didier.Donsez@imag.fr
URL: http://www-adele.imag.fr/~donsez
---------------------------------------------------------
Re: [jira] Created: (FELIX-68)
Posted by Karl Pauls <ka...@gmail.com>.
On 5/3/06, Francesco Furfari (JIRA) <ji...@apache.org> wrote:
> UPnP Events and Event Admin service
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
>
>
> UPnP Events and Event Admin service
> --------------------------------------
>
> Key: FELIX-68
> URL: http://issues.apache.org/jira/browse/FELIX-68
> Project: Felix
> Type: Sub-task
>
> Components: UPnP Device Service
> Versions: 0.8.0
> Reporter: Francesco Furfari
>
>
> We have to integrate the Event Admin Service (see Karl Pauls implementation) as
> described in section 112.9 of UPnP Device Service Specification 1.1
I've attached a starting point for a UPnPEventToEventAdminBridge to
this issue. The comment, however, is only felix-developer readable -
that is a mistake but it's not really important.
> The objective of this new feature is not so clear to me :( I think we have discuss a bit
> about it.
What exactly is it you want to discuss? I might be lagging a bit until
Tuesday (due to some travelling).
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com