Re: DAP-ISSUE-130 (was: Draft Minutes 21 August 2013 teleconference)

Le 28/8/13 22:38 , Cathy.Chan@nokia.com a écrit :
>>>> <richt> ISSUE-130:
>>>>
>>> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-000
>>> 2/minutes-2013-07-24.html#item05
>>>
>>>>
>>>> <trackbot> Notes added to ISSUE-130 Enable variety of protocols (e.g.
>>>> UPnP, Bonour) with protocol independent developer code.
>>>>
>>>> richt: sent mail to list, introduces more problems to do this,
>>>> especially since no commonality among the various protocols
>>>>
>>> JCD: I think you are missing the point: this proposal allows searching
>>> for a fragment of the service type, which means something like wildcards.
>>> If you request "fragment", it is like allowing a request for
>>> "*fragment*" (or maybe just "fragment*" if your fragment starts with a
>>> protocol prefix) Currently, you just cannot do this.
>>> Which means you cannot implement a service manager web app, which
>>> would explore the home network, and understand which higher level
>>> services the web app can offer the user.
>>> E.g. if the web app sees a phone and a TV on the network, it will
>>> propose to start another web app which organizes the display of new
>>> pictures from the phone on the TV.
> OK. I think I now understand the use case you have in mind. I agree it's an interesting one that the current API may or may not readily supports.
>
>>> As there are many possible services, requesting specific discoveries
>>> to see of each service is currently runnable or not will be impractical.
> Why is that? Wouldn't the service manager still know what specific service types the various web apps are capable of handling? The list might be long, but it wouldn't be infinite, would it? For instance, the service manager would know that a certain web app is able to use "urn:schemas-upnp-org:service:printbasic:1" and another web app is able to use "urn:vendorX-com:service:print:1". While it can perform a "fragment" search for "print", it would have no use of a local service that runs "urn:vendorZ-com:service:printpicture:1". In that case, why not search for "urn: schemas-upnp-org:service:printbasic:1" and "urn:vendorX-com:service:print:1" to begin with?
JCD: With a static, but long, list of possible tasks, I see 
impracticality in two places:
- for the author, web app script code that is much longer and more complex
- for the user, many responses to allow discovery requests required 
instead of just one

In my scenario, the author codes one async request for discovery of 
anything, the user needs to authorize a request to discover anything by 
this task manager web app, says yes once and for all, then the web app 
receives a list of discovered services and the author then synchronously 
matches the discovered services with the requirements of possible tasks 
to deduce the list of runnable tasks, etc...

With the current spec, the author needs to go through the list of 
possible tasks, and make an async request for discovery for each 
possible task to determine if it is runnable. The user needs to 
authorize one request for discovery per possible task. Impractical are 
the number of async discovery requests in the web app and the number of 
authorization requests to the user upon execution.

>
> Or do you envision that the service manager would dynamically broker the discovered services to web apps without knowing what service types they support ahead of time?
JCD: The task manager needs to know which service is required by which 
task regardless of whether the list of possible tasks is static or 
dynamic, I think.


>
>>>   From a perspective of reducing the security related interactions with
>>> the user, it is better that the service manager web app is given once
>>> the full authority to discover everything on the network (which
>>> requires wildcards or fragment search) rather than have as many
>>> requests for discovery as there are services to be tested for their ability to
>> run.
> The service manager can easily lump all services to be tested into a single discovery request rather than issuing one request per each service. That would result in a single user interaction point for permission.
JCD: Oh! Are you seriously suggesting a getNetworkServices call with 
say, a hundred or more service types ?
Again, this is placing a ridiculous constraint onto the web app author, 
rather than implementing a straightforward extension of the current spec.
And when I say "straightforward extension", I have implemented it and 
been using it for months: it is less than 50 additional lines of code, 
and would work with any of the UPnP and mDNS libraries I have looked at.

>
> Additionally, as I stated in my earlier comment [1], it would be tricky for the UA to issue a search request for wildcard service types.
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jul/0025.html
JCD: Actually, I did not understand why you made that point.

Quoting you: "But what if a UA does not monitor the network for device 
announcements, and only issues a search for the requested service 
type(s) when getNetworkServices is invoked? What UPnP search target 
would the UA use to search for services on the network? Specifically, 
what domain should it use when constructing the search target?"

Is there a practical situation where a UPnP-enabled UA does not monitor 
the network for device announcements ?
I do not see one. I would think such a UA to be incomplete, and yes, it 
would not be able to respond to such request.
In other words, my proposed change would imply that the UA monitors the 
network for device announcements.
In which sense could it be a problem ?
Best regards
JC
-- 
Télécom ParisTech <http://www.telecom-paristech.fr> 	*Jean-Claude 
DUFOURD <http://jcdufourd.wp.mines-telecom.fr>*
Directeur d'études
Tél. : +33 1 45 81 77 33 	37-39 rue Dareau
75014 Paris, France

Site web <http://www.telecom-paristech.fr>Twitter 
<https://twitter.com/TelecomPTech>Facebook 
<https://www.facebook.com/TelecomParisTech>Google+ 
<https://plus.google.com/111525064771175271294>Blog 
<http://jcdufourd.wp.mines-telecom.fr>