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

On Tue, Oct 15, 2013 at 7:02 AM, Igarashi, Tatsuya <
Tatsuya.Igarashi@jp.sony.com> wrote:

> 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.****
>
> **
>
My understanding was that this is not required but I agree this text seems
to suggest otherwise. Rich?


/g

Received on Tuesday, 15 October 2013 14:42:01 UTC