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: Rich Tibbett <richt@opera.com>
Date: Wed, 16 Oct 2013 03:46:04 +1100
Message-ID: <CAAsrAZAA190vfUTjkHYxhXEAZ1D0VwHpSaMDjx4k02gDUUk1cQ@mail.gmail.com>
To: Giuseppe Pascale <giuseppep@opera.com>
Cc: "Igarashi, Tatsuya" <Tatsuya.Igarashi@jp.sony.com>, "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>
On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
> On Tue, Oct 15, 2013 at 7:02 AM, Igarashi, Tatsuya
> <Tatsuya.Igarashi@jp.sony.com> wrote:
>> Hi Giuseppe,
>> On Wed, Oct 16, 2013 at 1:41 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
>>> 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 . getNetworkServices ( type )
>> Immediately returns a new Promise 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.

While this type of API usage is technically possible it would be a
less than ideal pattern for web developers to use.

Why? When we share a service with a web page that has not demonstrated
any prior awareness or interest in that service's corresponding type
then there is a good possibility that the web page does not know or
does not need to know how to interact with it if/when it received a
service object of that type.

Calling getNetworkServices twice as you propose above - initially to
determine the services running on a device and then calling it again
with a list of all service types discovered from the first call -
introduces this exact problem. The argument is "I don't know exactly
what services I want or will receive but I just want them all for the
sake of having them all". This does not fulfil the key requirements of
this API: being able to interact with all services returned to a web

Perhaps we could discuss a specific use case or scenario where a
pattern of calling getNetworkServices twice as above would be more
useful than calling getNetworkServices once against a list of service
types that are well-known to the requesting web page and thus are
presumably handleable by that web page should they be returned from
that call?

>> 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?

I can try to clean up this sentence. Of course it is worth pointing
out here that most of the UI/UX is quite deliberately left out of the
scope of this spec.

I would suggest both of the interpretations of user prompting made
above could be potentially valid but such UX decisions fall to
implementers. We shouldn't need to say much more than this in this

- Rich
Received on Tuesday, 15 October 2013 16:46:31 UTC

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