W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

RE: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)

From: Youenn Fablet <Youenn.Fablet@crf.canon.fr>
Date: Fri, 11 Oct 2013 16:09:57 +0000
To: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>, "Tatsuya.Igarashi@jp.sony.com" <Tatsuya.Igarashi@jp.sony.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>, "giuseppep@opera.com" <giuseppep@opera.com>, "richt@opera.com" <richt@opera.com>
Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE2F5399DC@ADELE.crf.canon.fr>
> Your understanding is correct. And this is the crux of this proposal. Let's say
> there is a device X with services A and B. With the current spec, the UA would
> store an object for A and an object for B, each with their respective service
> types. A web page would invoke the getNetworkService method with the
> respective UPnP service type as an argument to find each of these services.
> (To find both services, it would need to invoke the getNetworkServices
> method with both service types in the argument.) This proposal adds another
> object for X, with its device type stored. This enables a web page to invoke
> the getNetworkService method with a UPnP device type as an argument
> instead, and the existing algorithm for processing that call would locate the
> object for X and (upon user permission) pass it on to the web page. Upon
> parsing the config information, the web page would have information on
> both services to interact with them.

Thanks for the explanations.
I can see some potential downsides:
- Some nice NetworkService features would not be available: UPnP event subscription, onavailable/onunavailable service events.
- Whitelisting would not be applied even if some services are eligible to that. CORS detection may not be done properly as well.
- From the point of view of the web app, this object would be used in a very different way from other NetworkService objects.
A web app could also achieve similar goals by requesting a service type and retrieving the config information from the corresponding NetworkService. The difference between the two approaches is that a user may be presented more devices with the service-type request than the device-type request.

Received on Friday, 11 October 2013 16:10:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC