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 18:29:05 GMT
On second thought, I guess it is sufficient to only register an
UPnPEventListener in the bridge in case that there is at least one
EventAdmin present and at least one EventHandler interested in a
matching topic.

That way you end-up with two levels of degradation. First, in case no
bridging is needed, the bridge shouldn't be installed. Second, in case
bridging is potentially needed it is only done if at least one
EventAdmin and one interested EventHandler is available.

I don't think that it makes much sense to do anything more
sophisticated then that. It is a small change that I could commit as
soon as we have consensus.

What do you think?

regards,

Karl


> 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).
>
> regards,
>
> Karl
>
> 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
> karlpauls@gmail.com
>


-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message