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

> From: ext Youenn Fablet [mailto:Youenn.Fablet@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.
Indeed UPnP event subscription will not be available. The onavailable/onunavailable events will still be available, but they will be on the NetworkService object that represents the device, which is actually more logical as all services within a device always become (un)available simultaneously. 

> - Whitelisting would not be applied even if some services are eligible to that.
By setting the url attribute of the NetworkService object representing a device to the base URL, all services should be available since the controlURLs are relative to the base URL (unless the base URL has a path component and a controlURL is something like "/xxx").

> CORS detection may not be done properly as well.
Yes this could be an issue. (Note that this proposal was created before CORS came in. I imagine it would need some tweaks to work with CORS.)

> - From the point of view of the web app, this object would be used in a very
> different way from other NetworkService objects.
Unfortunately this is the tradeoff we had to make to keep the API simple. If there's sufficient support for the device search usage, we might be able to convince ourselves to go for more drastic changes. 

> 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.
> 
Please see http://lists.w3.org/Archives/Public/public-device-apis/2013Oct/0122.html for an example.

- Cathy.

> Regards,
>  Youenn

Received on Wednesday, 16 October 2013 19:27:02 UTC