Re: NSD spec implementation feedback

Youenn

Thank you for very much making constructive feedback on the Network Service Discovery specification [1]. 

As I noted in my early message today [2], I think we need to review the use cases and requirements to better understand how to resolve questions related to the overall model including abstraction, name visibility,  and necessary functionality, in the interest of  implementation and adoption. We discussed this on today’s DAP conference call [3].

Your points 1-3 emphasize the need for simplicity and a consistent model that is usable in practice, so they should all be taken into account going forward ( I’ve added issues for them).  Please see specific responses inline below.

Regarding #4, I believe Rich may be sharing more related to using sockets. I am not quite sure whether or how this needs to be coordinated/related to Network Service Discovery, as it seems to be a different approach. Once we have more concrete material on the list we should discuss - again this is an issue of needed functionality at the right level of abstraction.

I apologize for the delay in responding to you, sometimes I wait for list discussions to settle. In this case I may have waited too long, but you raise good questions and more feedback is welcome.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, DAP
@fjhirsch


[1] http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0022.html

[2] http://lists.w3.org/Archives/Public/public-device-apis/2014May/0021.html

[3] http://lists.w3.org/Archives/Public/public-device-apis/2014May/att-0022/minutes-2014-05-15.html

for tracker, this completes ACTION-690

On Apr 22, 2014, at 4:23 AM, ext FABLET Youenn <Youenn.Fablet@crf.canon.fr> wrote:

> Please find below some hopefully constructive feedback we gathered while implementing the NSD API.
> 
> Regards,
>                 Youenn
>  
> 1.       A single query type is easier to translate to a question that a user can understand and answer.
> In most cases we encountered, a single query type is sufficient.
> Having something like “this app wants to discover printers” is more meaningful than “this app wants to discover local services”.
> 
> In cases where more than one type is needed, having several specific queries in parallel seems better than one catch-them-all query.
> The user agent keeps the freedom to organize its UI (group parallel queries or not).
> Web application will find it also more convenient (no need to filter services according their service type).

Added tracker ISSUE-160

This seems aligned with additional feedback we received that domain specific use cases are clearer and easier to work with as appropriate abstractions such as print and 2nd screen, see http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0025.html

We need to address this going forward and having clearer use cases should help

>  
> 2.       Returning an array of services is not flexible.
> Progressive discovered service return (like sending an event per granted service) seems a better choice than a fixed array of services.
> This model is closer to existing discovery node.js modules.
>  
> This gives the flexibility to the user agent to send discovered services at various times:
> - according the granting process (always-granted services, user-clicked-granted services…)
> - according the discovery process (new service appearing).
> Also, recalling the NSD API when a new service is appearing may not be that efficient, both for web app (user denied a previously agreed service, by mistake?) or for user (which service is new?).
>  

Added as tracker ISSUE-161


> 3.       The prescriptive bindings to the low-level discovery protocols cannot always be ensured
> If implementers start from scratch, the current bindings are very good and detailed.
> If implementers start from existing libraries (avahi, gssdp e.g.), the exact control of the discovery process is not always guaranteed.
> Having these sections as normative adds perceived complexity (particularly the SSDP binding) and may pose questions related to testing and conformance.
>  

Added as tracker ISSUE-162

This appears to be another issue related to adoption and implementation as well as appropriate abstraction/model for use cases


> 4.       NSD spec is solely targeted at XHR.
> Primary goal of NSD should be discovery of HTTP services.

do we need to consider JSONP for cases where CORS is not suitable?

> But there are other means of communication (WebRTC, Raw socket API, chromecast, Presentation-API like communication channel…) that would all benefit from the NSD API.

are you suggesting that we can further simplify by removing some communication specific aspects and abstracting more?

> Making that clear (and maybe reorganize the spec accordingly) would make the spec more appealing.
>  
> It is not that clear what would be the impact on the API (no change, surface the expected communication channel in the API?).
> More discussion on the integration of NSD with other ongoing communication efforts seems useful.