W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2014

Network Service Discovery Issues & Next Steps

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 15 May 2014 09:49:12 -0400
Message-Id: <84B350F5-6AAD-48E0-A11C-6B114C490AD4@fjhirsch.com>
Cc: Frederick Hirsch <w3c@fjhirsch.com>
To: "APIs WG Device <public-device-apis@w3.org>" <public-device-apis@w3.org>
The 20 Feb 2014 WD publication of Network Service Discovery captures the current state of the specification

http://www.w3.org/TR/2014/WD-discovery-api-20140220/

We’ve had much discussion on the list regarding the technical approach and various issues.  A number of issues are listed on the DAP issues tracker, in addition there are some that are not.  We also have had questions about obtaining browser and implementer support as well as whether our implementation criteria are correct.

I suggest we re-visit the higher level concerns before delving into details, as we may wish to adjust our overall approach.

The specification is generic, so this adds complexity. Perhaps we should narrow the use cases down to three to see if we can simplify and/or get at the fundamental aspects.

(1) we need better understanding and documentation of use cases and requirements, at a more specific detail

One case is Web & TV, we need detail on the actual use cases and requirements: http://lists.w3.org/Archives/Public/public-device-apis/2014May/0019.html

Another discussion is pushing content to local network devices as simpler than pulling, see http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0027.html 

(2) Handles/Naming/Abstraction: Can/should the API hide local network details from applications via translation 

This can address security and privacy/fingerprinting concerns but has issues related to linkage to network data transfer after discovery , also user friendly naming etc

Mark Vickers notes that abstraction is used for window.print and also 2nd screen cases ( http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0025.html )

We may need concrete use cases for the approach rather than making generic

Idea here is whether we can support handles and naming

(3) Implementation assumptions, browser extension rather than in browser core

Maybe we should count Jean- Claude implementation as useful for interop.

http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/2014Apr/0033.html

(4) Specific feedback on spec needs to be addressed

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

(5) Issues list

http://services.w3.org/xslt?xslfile=http://www.w3.org/2009/dap/issues.xsl&xmlfile=http://www.w3.org/2009/dap/track/issues/open%3fsort=id&recurse_auth=on&content-type=&submit=transform

We should discuss these items and next steps on the call

regards, Frederick

Frederick Hirsch, Nokia
DAP Chair
@fjhirsch
Received on Thursday, 15 May 2014 13:49:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:07 UTC