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

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>