Re: [discovery] Adding CORS to NSD API - proposal and issues

On Mon, Oct 7, 2013 at 10:13 AM, FABLET Youenn
<Youenn.Fablet@crf.canon.fr>wrote:

>  Searching by service type seems appropriate from a web app point of view.
> ****
>
> As Rich said, a web app may just need ContentDirectory service access
> (slideshow) while another may need access to all ContentDirectory,
> ConnectionManager and AVTransport services (streaming). ****
>
> It makes sense to keep it that way.****
>
> **
>
OK, but should an app be allowed to search for UPnP "devices"? As a way to
say "I only want services of a given device type"? (and don't care of
similar services associated to other device types?)


> **
>
> Granting access at a device level seems more comprehensive from a user
> point of view.****
>
> It is also probably more consistent with UPnP design.****
>
> But at the end of the day, this is a browser UX decision (power users may
> still prefer a pick-service-by-service UX). ****
>
> I am not sure why the NSD API should actually define constraints here.****
>
> **
>
Not completely sure about this, but I don't think is critical at this point.

>
> **
>
> Enabling partial exposure of a device has also some benefits.
>

but can also lead to confusing situations isn't it? where you don't know
why only some services are exposed/available.


>  ****
>
> The web app can parse the UPnP device description to request user specific
> actions like activate a given missing service or grant a given service.
>

How would this work (after the parsing part, I mean)? You mean just parse
the description are ask the user to "enable" such service? (that is
probably going to be an obscure message to most users, isn't it?)

/g