Re: Draft Minutes 21 August 2013 teleconference

I apologize for not being present in the call where this was discussed, 
but I have been present on the list for months with few answers to my 
questions and I cannot be present on all calls when the probability of 
NSD being actually discussed is very low (2 calls in the last months, 
one of which during my absence).
Further comments on yesterday's call inline.
>
>
>       Network Discovery
>
> fjh: additional comment, Cathy: 
> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/0028.html
>
> richt: some of the issues can be closed
>
> ISSUE-129?
>
> <trackbot> ISSUE-129 -- Simplify Network Service Discovery API -- open
>
> <trackbot> http://www.w3.org/2009/dap/track/issues/129
>
> ISSUE-130?
>
> <trackbot> ISSUE-130 -- Enable variety of protocols (e.g. UPnP, 
> Bonour) with protocol independent developer code -- open
>
> <trackbot> http://www.w3.org/2009/dap/track/issues/130
>
> <richt> ISSUE-129, we talked about this at some length in a previous 
> conf call: 
> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item03 
>
>
> fjh: I think we need to seriously consider extension points, pulling 
> Dial out etc
>
> cathy: this is a separate issue
>
> richt: these two should be closed
> ... re ISSUE-129 jean claude has different model in mind, 
> specification allows different interaction mechanisms, levels so 
> events allow different models
>
> <richt> Regarding ISSUE-129, JCD is looking at this from one 
> implementation perspective: return zero services then use the 
> onserviceavailable event to then re-call getNetworkServices....
>
JCD: While it is true that I have one implementation, in this particular 
case, I am actually looking from the author's perspective, trying to 
reduce the clutter in web apps using NSD.
And Rich is speaking only from the implementer's perspective.
Guys, you have to give more importance to the authors!
But this is a matter of taste.

> <richt> a user agent MAY return 1 or more services on the first call, 
> making the onserviceavailable event useful for monitoring changes on 
> the network.
>
> <richt> Allowing that kind of flexibility is good.
>
> <richt> Therefore we don't want to change the specification as 
> suggested in ISSUE-129.
>
> <richt> we also discussed this in 
> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/minutes-2013-07-24.html#item03 
>
>
> <richt> ISSUE-130: 
> http://lists.w3.org/Archives/Public/public-device-apis/2013Aug/att-0002/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.
As there are many possible services, requesting specific discoveries to 
see of each service is currently runnable or not will be impractical.
 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.
So 130 is not a matter of taste, and I disagree with the summary 
judgement that closed it.

> <Cathy> +1 on closing ISSUE-129 and ISSUE-130
>
> richt: so that proposal is not mature
>
> close ISSUE-129
>
> <trackbot> Closed ISSUE-129.
>
> close ISSUE-130
>
> <trackbot> Closed ISSUE-130.
>


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