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.

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

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.html
> [2] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0012.html
> [3] http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0003.html

Received on Saturday, 20 July 2013 00:57:18 UTC