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

comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Oct 15, 2013, at 12:46 PM, ext Rich Tibbett wrote:

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

This also goes against the privacy principle of minimization - the web page should not inventory all the services but only access what it needs by asking for what it needs.



> 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 Thursday, 17 October 2013 15:16:50 UTC