Re: [discovery-api] Supporting UPnP devices

+1.

The url for UPnP device could be the url to device description document?

Thanks,
Kikkawa

On Tue, 19 Mar 2013 06:59:29 +0900
"Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com> wrote:

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

--------------------------------------------------------------
 Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
  Sec.1  Dept. No.2
  Cloud Technology Development Div.
  COR&D Sony Corporation
 (TEL) +81 50 3750 3953 
--------------------------------------------------------------

Received on Tuesday, 19 March 2013 03:24:11 UTC