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

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

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

Raised by: Frederick Hirsch
On product: Network Service Discovery

from email: http://lists.w3.org/Archives/Public/public-device-apis/2013Mar/0013.html

There has been on and off discussion on whether the discovery API should
support UPnP device discovery by device type. See e.g. [1], [2], [3]. At the
March 6 DAP call we had consensus to explore supporting UPnP devices in the
discovery API, and I agreed to take a deeper look at the implications of such
a change and make a proposal. Below are some key findings that I think are
worth discussing.

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. 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 Tuesday, 9 July 2013 17:20:55 UTC