RE: [discovery-api] Supporting UPnP devices

> -----Original Message-----
> From: ext Rich Tibbett [mailto:richt@opera.com]
> Sent: Tuesday, March 19, 2013 12:53 AM
> To: Chan Cathy (Nokia-CIC/Boston)
> Cc: public-device-apis@w3.org
> Subject: Re: [discovery-api] Supporting UPnP devices
> 
> 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.)
> 
> Interesting analysis.
> 
> >
> > 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.
> 
> We could detach the url, type and onnotify attributes completely from
> NetworkService objects and supply all 'access point'-like info (type, url
and
> onnotify) via a set of indexed properties on each NetworkService object?
> 
> So a NetworkService object itself can represent zero or n number of
indexed
> properties each providing some separate access point info that could have
> been obtained from either a UPnP or Zeroconf service or device. We would
> also likely add a few helper methods to the NetworkService interface e.g.
> length, getServiceByType.
> 
> navigator.getNetworkServices('upnp:urn:schemas-upnp-
> org:device:MediaServer:4',
> function(services) {
>    for(var i = 0; i < services.length; i++) {
>      var service = services[i];
>      for(var j = 0; j < service.length; j++) {
>        var accessInfo = service[j];
>        console.log(accessInfo.type + ": " + accessInfo.url);
> 
>        // Do something with the access point info
>        // ... e.g. ...
>        var xhr = new XMLHttpRequest();
>        xhr.open('POST', accessInfo.url, false);
>        // ...
>        // xhr.send(someRequestBody);
>      }
>    }
> }, function(err) { console.dir(err); });
> 
> This makes the design of the NetworkService interface similar to how the
> NetworkServices interface currently works in the spec. That's probably a
> Good Thing.
> 
That would do, as long as we don't mind the additional layer to get to the
meat (the url) of simpler services like mDNS. The other question is whether
it would now be too awkward to have NetworkService objects with a type that
is a UPnP service type. Or should we turn all UPnP-based NetworkService
objects into UPnP devices, even when getNetworkServices was invoked with a
UPnP service type?

> >
> > 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.
> 
> I expect we're looking at a significant amount of effort to rewrite the
> UPnP related algorithms but I think this change gives us more
> flexibility in how we ultimately implement the specification.
> 
> Each 'service' object (if that is still the correct terminology) can
> have 0, 1 or n access points. That means we may also be able to provide
> access point information for things in the device description file
> (assuming we can bind them to 'type' names that make sense).
> 
> Just to clarify, I mean we now have the possibility of providing
additional
> 'asset' information via the indexed properties such as icon url endpoints
and
> description file url endpoints (e.g. SCPD urls) if we can come up with a
good
> way to describe their 'type'.
> 
I like that. I would call those indexed properties resources or assets as
you referred to them in text. services[i].service[j] in the above example
confuses the heck out of me. :-)

> e.g.
> 
> // adding to the example code provide above if( service[j].type ===
> 'upnp:icon' ) { // for example
>    someImgElement.src = service[j].url;
> }
>
> Thanks for kicking this off, Cathy. It is always great to discuss around
> the spec itself.
> 
> - Rich
> 
> >
> > 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
> >
> >