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

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

From: Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com>
Date: Tue, 15 Oct 2013 14:02:36 +0900
To: Giuseppe Pascale <giuseppep@opera.com>
CC: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>, "Youenn.Fablet@crf.canon.fr" <Youenn.Fablet@crf.canon.fr>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "richt@opera.com" <richt@opera.com>
Message-ID: <DAB1CC3FAB54D3438F667F8E7B7599A20217C88446F0@JPTKYXMS218.jp.sony.com>
Hi Giuseppe,

I don't think this is the case, as how permission is asked is not mandated by the spec and the UA may request only once per device, regardless of the number of service searches you do (maybe by showing which services will be exposed)

In the case that a web application specifies multiple types to the getNetworkService method, do you mean how many dialogs pop-up is implementation dependent ?

promise = window . navigator<http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#navigator> . getNetworkServices<http://www.w3.org/TR/discovery-api/#dom-navigator-getnetworkservices> ( type )
Immediately returns a new Promise<http://dom.spec.whatwg.org/#promises> object and then the user is prompted to select discovered network services that have advertised support for the requested service type(s).
In my understanding that UA must prompt per getNetworkServices method. And I  assumed the case that a web application searches UPnP Service B after searching UPnP Service A which is founded in the Device Description of UPnP Device X. This case causes two popup dialogs by the two getNetworkServices() methods. I do not think that all web application must know what UPnP services are supported by UPnP device in advance of getting UPnP device description.

BTW, the about description “the user is promoted to select discovered network services…” would not be correct. I think it should be “the user is prompted to allow providing network service information discovered on local network”, because UA does not support service selection.

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>)
Information Technology Development Div, R&D Platform
Sony Corporation






From: Giuseppe Pascale [mailto:giuseppep@opera.com]
Sent: Friday, October 11, 2013 11:23 PM
To: Igarashi, Tatsuya
Cc: Cathy.Chan@nokia.com; Youenn.Fablet@crf.canon.fr; public-device-apis@w3.org; richt@opera.com
Subject: Re: [discovery] DAP-ISSUE-131 Support UPnP device discovery by Device Type? (was RE: [discovery] Adding CORS to NSD API - proposal and issues)

On Fri, Oct 11, 2013 at 4:08 PM, Igarashi, Tatsuya <Tatsuya.Igarashi@jp.sony.com<mailto:Tatsuya.Igarashi@jp.sony.com>> wrote:
Hi Youenn and Cathy,

Cathy described what I want to say. I would add the two issues if searching UPnP device is not supported by NSD at all.

(1) Multiple popup dialog per UPnP service type.
Searching both A and B of UPnP service types of X UPnP device will cause two popup dialog for user agreement by the promise of getNetworkService() method. Practically, most UPnP application would like to control a whole function of UPnP device. For example, controlling volume and playback requires to control both UPnP Rendering control and UPnP AV Transport services, two pop-up dialogs per UPnP service type would confuse consumers even if a web application unifies the two UPnP services in a UPnP device and show the list of UPnP devices for user selection.

I don't think this is the case, as how permission is asked is not mandated by the spec and the UA may request only once per device, regardless of the number of service searches you do (maybe by showing which services will be exposed)

As I pointed out in the other thread, there is another issue though: if I'm only interested in service A when is inside device X, why should I search for all services of type A that will generate confusing requests to the user for devices that are not really related to the type of content my application may be able to handle?

/g
Received on Tuesday, 15 October 2013 05:03:11 UTC

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