RE: [discovery-api] Supporting UPnP devices

Hi Doug,

This is the approach we are taking in the W3C SysApps WG. However, note that web system applications run in a secure runtime environment and system applications are "installed". This is different from the normal browser sandbox model and I am not sure that it would be possible to open up a raw socket API in the browser due to security issues.

I am editing the SysApps raw socket API, http://raw-sockets.sysapps.org/. This version is based on the "traditional well-proven Berkeley socket style" and I believe it will work well. However, based on comments from the WG I am currently in the process of rewriting the API to simply it and create a more "webish" API of a style similar to other SysApps APIs.

Best regards
  Claes

________________________________________
From: Doug Turner [doug.turner@gmail.com]
Sent: Friday, March 22, 2013 4:48 AM
To: Cathy.Chan@nokia.com
Cc: public-device-apis@w3.org
Subject: Re: [discovery-api] Supporting UPnP devices

Has anyone consider *not* doing this, and instead supporting UDP and TCP
raw sockets directly thus allowing someone to write this stuff as a js
libary?

Doug



On 3/18/13 2:59 PM, 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
>
>

Received on Friday, 22 March 2013 08:27:00 UTC