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

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

From: Giuseppe Pascale <giuseppep@opera.com>
Date: Mon, 7 Oct 2013 12:00:38 +0200
Message-ID: <CANiD0kopFFZRZqnua4kbFCqM43uK-AY8kM1AN-1oR23X+mPjmw@mail.gmail.com>
To: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Cc: Rich Tibbett <richt@opera.com>, Device APIs Working Group <public-device-apis@w3.org>
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
Received on Monday, 7 October 2013 10:01:25 UTC

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