- From: Rich Tibbett <richt@opera.com>
- Date: Wed, 16 Oct 2013 03:46:04 +1100
- 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 page. 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 specification. - Rich
Received on Tuesday, 15 October 2013 16:46:31 UTC