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

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

Regards,
 Youenn

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