RE: DAP-ISSUE-131: Support UPnP device discovery by Device Type? [Network Service Discovery]

Comments inline.

> -----Original Message-----
> From: ext Rich Tibbett [mailto:richt@opera.com]
> Sent: Friday, July 19, 2013 8:57 PM
> To: Device APIs Working Group
> Subject: Re: DAP-ISSUE-131: Support UPnP device discovery by Device Type?
> [Network Service Discovery]
>
> On Tue, Jul 9, 2013 at 7:20 PM, Device APIs Working Group Issue Tracker
> <sysbot+tracker@w3.org> wrote:
> > DAP-ISSUE-131: Support UPnP device discovery by Device Type? [Network
> > Service Discovery]
>
> > The first thing is I'd assume that we want to continue supporting
> > searching for individual UPnP services, in addition to searching for
> > UPnP devices which contain UPnP services. By this I mean that a web
> > app would continue to be able to search for say a ContentDirectory
> > service and obtain a NetworkService object that represents the
> > service, regardless of what UPnP device that service resides in. In
> > addition to that, a web app would also be able to search for a say
> > MediaServer device and obtain an object that represents the UPnP
> > device, which in turn contains a ContentDirectory service. I believe
> > this is important as there are "add-on" UPnP services that are not tied to
> any particular device types.
>
> Herein lies the rub. The objective of this API is to be able to _communicate
> with obtained networked services_, not simply to be able to detect their
> existence in the network and supply defunct objects back to a web app.
> Being able to detect (potentially proprietary) "add-on" services is only 
> really
> useful if the web app is capable of communicating with that given service
> type.
>

By "add-on" services, I was not referring to services that vendors create. I 
was referring to [standard/well-known] UPnP services that are not necessarily 
tied to particular device types [1]. We all know that the MediaServer device 
is defined to contain a ContentDirectory (and optionally a ConnectionManager 
service). An application looking for a Content Directory can choose to either 
search for a MediaServer device or for a ContentDirectory service directly. 
Either search would result in the discovery of the desired Content Directory. 
However, there are many other standard UPnP services that are not defined to 
be in any particular device types, but can be contained in any UPnP device 
types. Examples are the DeviceProtection service [2] and the QoSManager 
service [3], which can be used in any device type. I was arguing that in order 
to support such service types that have no well-known associated device types, 
we have to continue supporting search by service types even as we add 
searching by device types.

> The current API allows a developer to obtain such "add-on" services if they
> know that service's type up-front. Knowing the service's type before
> obtaining that service is step 1 on the path to being able to interact with 
> that
> service. Step 2 is understanding what API that service supports and step 3 
> is
> actually writing code to interact with that service when it is detected and
> returned and thus being able to interact with that service and thus 
> fulfilling
> the original objective when obtaining that service in the first place.
>
> It's important to understand here that the Network Service Discovery API
> does not support service description (SCPD) lookups as a core requirement.
> That is, in my opinion, a largely defunct part of the UPnP Services
> Architecture specification. Either a developer knows how to communicate
> with a UPnP service up-front or they don't. Learning about the actions that 
> a
> UPnP service supports in real-time, as the app is running, is largely uselss
> until/unless the developer knows what do with those actions and how to
> plug those actions in to their web app in real-time. That does not seem to
> reflect how developers interact with APIs on the web today (though I hold
> out hope that intelligent self-describing and self-organising API 
> interaction is
> just around the corner).
>

Many UPnP services define optional state variables and actions. The usage and 
interactions are well defined by the standard and are well-known to 
developers, but they may or may not be implemented by a service. It is through 
the SCPD that the service communicates to control points which of these 
optional elements it supports. (Of course, it can also include vendor-defined 
state variables and actions. In such cases, the usage and interactions of such 
may not be known to the developer as you stated.) For example, the 
ContentDirectory service defines the Search and CreateObject actions, which 
are optional. Typically a control point would inspect the SCPD to determine 
the functionalities available at a service and present them to the user 
accordingly. I would expect a web-app to do the same.

And that is why we argued for whitelisting resources other than just the 
control URL. (Initially [4] and [5], consolidated at [6] and latest at [7].)

[1] http://upnp.org/sdcps-and-certification/standards/sdcps/
[2] http://upnp.org/specs/gw/deviceprotection1/
[3] http://upnp.org/specs/qos/qos3/
[4] http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0101.html
[5] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0014.html
[6] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0052.html 
(B5)
[7] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0041.html

Regards, Cathy.

> The alternative, and the process supported today, is for the web app to
> declare the services it expects to utilize _and is capable of communicating
> with_ up-front in the initial getNetworkServices call.
> >From there, the concept of a 'device' can be re-constituted by
> comparing the 'deviceId' attribute, if it is available, on each 
> NetworkService
> object.
>
> Obtaining a bunch of potentially unknown networked services by device type
> that a web app is then not able to communicate with is perfectly useless.
> That seems to be the main benefit proposed by this request:
> searching for X number of services by device type, each with a service type
> that is potentially unknown to the current web app. That may be great for
> getting a bunch of JavaScript objects, each one representing a networked
> service, but if you can't read or write to the provide URL endpoint in each
> object, what is the point in providing them to the web app in the first 
> place?
> On the other hand, if the web app requests services explicitly because it
> understands how to interact with them then we have ourselves a useful API.
>
> br/ Rich
>
> [1] Though there are ways in which this can be done by e.g. comparing the
> host, port and base path of Zeroconf-based NetworkService objects against
> each other. If they match then they may be considered as coming from the
> same physical device (note: that is a different definition from a UPnP
> 'device').
>
> > Besides, the flexibility may come in handy for some web app
> > developers.
> >
> > The biggest impact in adding UPnP device level support is on the object
> model.
> > The NetworkService interface currently consists of the following 
> > attributes:
> > * id
> > * name
> > * type
> > * url
> > * config
> > * online
> > and the following event handlers
> > * onserviceonline
> > * onserviceoffline
> > * onnotify
> >
> > While this works well for both mDNS and individual UPnP services (and
> > DIAL, which is a special case of UPnP), it isn't particularly suited
> > for representing a UPnP device. For one thing, a UPnP device does not
> > have a single url associated with it to send messages. Instead, each
> > of the services inside it would have one such url. Similarly, a UPnP
> > device itself does not receive event messages. The underlying services
> > do. Thus, a UPnP device does not need/utilize the url attribute and
> > onnotify handler. Instead, it needs an array of objects that
> > represents the underlying services. So, the difference between the
> > desired interface to represent a UPnP device and the current
> > NetworkService interface would be
> > - url
> > - onnotify
> > + services[]
> >
> > Now, if we look at the services objects to be included in a UPnP
> > device object, they need a little less than what is provided by the
> > NetworkService interface, as some of those would now belong to the
> parent device object.
> > Having them also at the service level would only make it more
> > confusing. Most notably, the online attribute and the associated
> > online/offline events belong to the parent device. The difference
> > between the desired interface to represent a UPnP service *residing
> > under a UPnP device object* and the current NetworkService interface
> > would be
> > - id
> > - name
> > - config
> > - online
> > - onserviceonline
> > - onserviceoffline
> > (In other words, the desired interface for a UPnP service needs only
> > type, url and onnotify.)
> >
> > My proposal would be to expand the NetworkService interface to add an
> > optional attribute for the services array and allow the url attribute
> > to be optional/nullable, with the caveat that the onnotify handler
> > would be entirely unused when the object represents a UPnP device. For
> > representing the UPnP service objects, I would propose introducing a
> > separate interface with only the necessary attributes/event handlers
> > instead of reusing the NetworkService interface to minimize confusion.
> > The name of the interface would need some serious thinking/bikeshedding
> though.
> >
> > Once we agree on the object model, most of the changes to add UPnP
> > device support should be rather straightforward. However, I do expect
> > to see some sub-steps in various algorithms that would look
> > significantly different for UPnP devices compared with the existing
> > services.
> >
> > Regards, Cathy.
> >
> >
> > [1]
> > http://lists.w3.org/Archives/Public/public-device-apis/2012Nov/0101.ht
> > ml [2]
> > http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0012.ht
> > ml [3]
> > http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0003.ht
> > ml