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

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

From: FABLET Youenn <Youenn.Fablet@crf.canon.fr>
Date: Mon, 7 Oct 2013 14:16:08 +0000
To: Giuseppe Pascale <giuseppep@opera.com>
CC: Rich Tibbett <richt@opera.com>, Device APIs Working Group <public-device-apis@w3.org>
Message-ID: <ACC41E833067BD4FB8084DEBA2D866BE2F538B67@ADELE.crf.canon.fr>
One should weight the added implementation complexity if both kinds of search are added.
I am not sure it is worth having both.
I probably need to have more thoughts on “service vs. device” search.

Note though that device-type search will not remove entirely the issue.
For instance, A UPnP MediaServer may not always run a AV Transport Service.
Web apps will need to deal with that anyway.


From: Giuseppe Pascale [mailto:giuseppep@opera.com]
Sent: lundi 7 octobre 2013 12:01
To: FABLET Youenn
Cc: Rich Tibbett; Device APIs Working Group
Subject: 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<mailto: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?)


Received on Monday, 7 October 2013 14:16:57 UTC

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