Re: DAP-ISSUE-133: Fix UPnP events subscription and unsubscription [Network Service Discovery]

I think eventing is a valuable part of the specification because it allows for initiation of communication from the other direction. However, I agree with JC about abstracting it from the underlying protocol.

-Clarke

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr<mailto:jean-claude.dufourd@telecom-paristech.fr>>
Date: Monday, August 19, 2013 5:13 AM
To: "public-device-apis@w3.org<mailto:public-device-apis@w3.org>" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Subject: Re: DAP-ISSUE-133: Fix UPnP events subscription and unsubscription [Network Service Discovery]
Resent-From: "public-device-apis@w3.org<mailto:public-device-apis@w3.org>" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Resent-Date: Monday, August 19, 2013 5:14 AM

It seems to me that this issue is wider than described.
There does not seem to be a description, in the specification, of the NSD interface to UPnP Events subscription.
There is a large discussion of what happens in the UA, but nothing about how to actually use it from the author's perspective.
The JS event "notify" and the field "onnotify" appear to be related to UPnP event subscription, but they are not defined.
UPnP event subscription is described in section 7 service discovery, which also seems wrong to me: subscription is not part of discovery.

If I understood correctly the intent (which I am not sure at all), I would suggest:
- creation of a separate section for network service events (NSE)
- definition of the interface to NSE and how it works independently from the UPnP implementation
And I would insist on an interface to service events that is independent from UPnP: one important purpose of the NSD specification is to abstract discovery away from underlying protocols and their implementations.

On an even wider perspective, I am wondering why UPnP Events are mentioned at all in the NSD spec.
UPnP Messaging has been repeatedly mentioned as outside of the scope.
Why would UPnP Eventing be in the scope and UPnP Messaging outside of the scope ? It does not make sense.
Best regards
JC

Le 30/7/13 23:43 , Device APIs Working Group Issue Tracker a écrit :

DAP-ISSUE-133: Fix UPnP events subscription and unsubscription [Network Service Discovery]

http://www.w3.org/2009/dap/track/issues/133

Raised by: Cathy Chan
On product: Network Service Discovery

This evolves from comment A7 in the consolidated comments in [1]. Follow-up comments are in [2], [3], [4], [5] and [6].

Essentially, the UPnP events subscription and unsubscription steps are not entirely correct. They should be fixed as follows.

- when a NetworkService object representing a local networked service is being added to any service manager for the first time, the UA sets up a UPnP events subscription with that service. The UA also begins to maintain a subscription list of NetworkService objects subscribed to that service.
- subsequently, when a NetworkService object representing the same local networked service is being added to additional service managers, the UA adds the NetworkService object to the subscription list associated with that local networked service.
- when a UPnP event arrives, the UA dispatches a notification event to each of  the NetworkService objects in the subscription list.
- when removing an available service (the local networked service is no longer online), the UA terminates UPnP events subscription associated with that service.
- when adding an available service (the local networked service comes [back] online), the UA re-initiates UPnP events subscription with that service. It also adds all NetworkService objects representing that service to the subscription list.
- when NetworkService objects are being garbage collected, the UA removes the NetworkService object from the corresponding subscription list. If the subscription becomes empty as a result, the UA terminates UPnP events subscription with the corresponding local networked service.

[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0052.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0007.html
[3] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0040.html
[4] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0049.html
[5] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0063.html
[6]* http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0071.html
*The content of [6] was unfortunately not properly archived. The relevant text is included here.
[[Having taken a closer look, this is still not right. The algorithm uses a
"service type in use" flag to determine whether to terminate the events
subscription, whereas something like "service in use" (*not type*) should be
used instead. In other words, you terminate the events subscription if
client is using a particular service, not if no client is interested in the
service type.

Even with that change, the unsubscription process is still a bit messy.
There are actually two trigger points for terminating an events
subscription. The first is when a local networked service gets disconnected
from the network (i.e. becomes unavailable). At that point, the events
subscription is effectively terminated implicitly, as the service would have
no recollection of the existing subscription when it comes back online. In
this case, all the UA needs to do is clean up its internal storage regarding
this subscription, and this should be part of the rule for removing an
available service. Note that to complement this, the UA also needs to
re-establish an events subscription when the local networked service comes
back online, if there are active service managers that include that network
service. This step is currently missing and should be added to the rule for
adding an available service. The second trigger point for terminating an
events subscription is when all the clients interested in that network
service are gone. In this case, regardless of the current status of the
local networked service, the UA would terminate the events subscription by
sending an unsubscribe message. The checking of this trigger point should be
when a service manager is being removed from the list of active service
managers. I believe this belongs to the garbage collection phase.]]






--
[Télécom                    ParisTech]<http://www.telecom-paristech.fr> Jean-Claude DUFOURD<http://jcdufourd.wp.mines-telecom.fr>
Directeur d'études
Tél. : 01 45 81 77 33   37-39 rue Dareau
75014 Paris, France

[Site web]<http://www.telecom-paristech.fr>[Twitter]<https://twitter.com/TelecomPTech>[Facebook]<https://www.facebook.com/TelecomParisTech>[Google+]<https://plus.google.com/111525064771175271294>[Blog]<http://blogrecherche.wp.mines-telecom.fr>