Re: Draft Minutes 21 August 2013 teleconference

Jean-Claude

I have re-opened ISSUE-130 so we can discuss this issue and close it after reviewing the points you raised.

Would you be able to attend the call next week to discuss (e.g 4 Sept)? I do not believe Rich will be on the call this week.

If so maybe we can discuss the issue on that call.

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group


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

Received on Tuesday, 27 August 2013 15:30:18 UTC