felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Pauls" <karlpa...@gmail.com>
Subject Re: Again on the UPnP and Event Admin service
Date Tue, 20 Jun 2006 16:50:07 GMT
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

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).



On 6/20/06, Francesco Furfari <francesco.furfari@isti.cnr.it> wrote:
> Dear all,
> I would like to re-open the discussion about UPnP and Event Admin (EA)
> (see felix-68
> http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200605.mbox/browser)
> because I think the current implementation has some drawbacks.
> Basically the implementation works fine but it implies an increment of
> the network communication, we could avoid with a specular implementation.
>  From the previous discussion we all agreed that a Bridge solution is
> the best approach. It is compatible with the previous R3 release, and
> UPnPDevice developers don't have to deal with the EA details.
> Anyway, the current implementation forces all UPnP devices to notify
> their internal changes to the Bridge in order to transparently dispatch
> the upnpEventNotify messages to the EA.
> Let me briefly introduce the original UPnP eventing mechanism to better
> explain why that solution implies a waste of resources. The Eventing in
> UPnP, like in Jini, is based on a leasing protocol in order to reduce
> the traffic on the network. When a Control Point needs a notification
> about some state variable changes, it sends a subscription message
> proposing a leasing time, after which it will renew the subscription.
> However in the leasing protocol is the UPnP device that ultimately
> decides the leasing, answering with the effective leasing time basing on
> its workload. Notice that a device is usually silent, and it delivers
> notification only if there are interested Control Points. From this
> point of view a device is not an autonomous data producer.
> So far, when the Bridge registers a UPnPEventListener with a NULL filter
> it obliges all the UPnP devices to notify their changes. In this
> scenario the UPnP Base driver is a broker that, as soon as listen for
> the registration of such listener, has to subscribe all the physical
> device on the network to receive their messages and to send once again
> to the Bridge, that in its turn will send to the EA. The EA, if there
> aren't data consumer with the right topic and filter, will spent all the
> time discarding them. At running, on the network, we will see the
> exchanging of a lot of HTTP messages (notification and renewal) that
> are, in my opinion a waste of resources and they break the original
> objectives of the UPnP Eventing specification.
> The solution I suggest consists of inverting the process of bridging the
> events, starting from the data consumers perspective. I attached a class
> diagram to illustrate this new approach.
> The Bridge listen for registration of EventHandler with UPnP topic, and
> registers an EventAdminAdaptor implementing the UPnPEventListener
> interface with the same filter used by the EventHandler. As soon as a
> valid UPnPDevice will notify some event to the adapter, it will delivery
> the message directly to the EventHandler (instead of using postEvent
> message). This schema works on demand without increase the trafic on the
> network and moreover we could also apply some optimizations.
> For example if there are many EventHandler registered with the same
> filter we could re-use the same Adaptor object to dispatch the events,
> that is the Adaptor can act as broker.
> Some final consideration on the R4 spec.
> The relationship between UPnP spec. and Event Admin spec. is a little
> bit  ambiguous. It does not state anything of wrong but my first
> impression, reading the EA spec, was that it came in help of the UPnP
> developers, being the communication mechanism it goes to propose an
> overcoming of the XXXListener on which UPnP spec is based.
> IMHO, as clarification, the coming revision of the R4 should better
> explain that the basic communication mechanism for the UPnP subsystem is
> always the same. And the UPnP developers should never deal with the EA.
> In the proposed scheme the postEvent message with UPnP topic is never
> used and it should be inhibited because any usage potentially represents
> a duplication of messages.
> The paragraph 111.9 should be moved in the EA service spec. because it
> only declare the properties that are used to bridging UPnP events.
> I my opinion the relationship between UPnP and EA is summarized in the
> The paragraph 113.1.1 - "OSGi events – The OSGi Framework, as well as a
> number of OSGi services, already have a number of its own events
> defined, for uniformity of processing these have to be mapped into
> generic event types". Hence the EA spec only come in help of users of
> UPnP devices (namely Control Points), they can either use the standard
> communication mechanism (UPnPEventLister) or the new one based on the
> EventHandler, if available.
> As last consideration about the EA spec., I was wondering whether the
> Karl's implemetation of immutable events (see Dictionary class in
> http://svn.apache.org/viewvc/incubator/felix/trunk/org.apache.felix.eventadmin.bridge.upnp/src/main/java/org/apache/felix/eventadmin/bridge/upnp/UPnPEventToEventAdminBridge.java?view=markup
> could be a valid alternative to the current implementation of
> org.osgi.service.event.Event class (see
> http://svn.apache.org/viewvc/incubator/felix/trunk/org.osgi.compendium/src/main/java/org/osgi/service/event/Event.java?view=markup
> ). In section 113.3.2 there are warnings about mutable objects used as
> property values, in fact the default implementation of the Event class
> does a soft copy of the dictionary. In the case of UpnP Events the
> property value is not immutable, thus the approach used by Karl.
> I would be expected to see in the EA specification the definition of a
> contract, based for example on the serializable interface or a deep
> clone implementation, among EA and EA clients, but overall the approach
> used by Karl is more simple.
> So, I would like to know your opinion on the matter and whether there is
> a general consensus I propose to modify the current UPnP Bridge
> implementation and the default implementation of the Event class.
> regards,
> francesco

Karl Pauls

View raw message