- From: Rich Tibbett <richt@opera.com>
- Date: Sat, 20 Jul 2013 02:12:09 +0200
- To: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>
- Cc: public-device-apis@w3.org
On Wed, Jul 17, 2013 at 11:44 PM, <Cathy.Chan@nokia.com> wrote: > On Tue, Jul 9, 2013 at 7:19 PM, Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org> wrote: >> >> DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol >> independent developer code [Network Service Discovery] ... >> So I propose to allow, as first argument of getNetworkServices, a plain string >> that is neither starting with "upnp:" nor "zeroconf:", in which case, the >> service type matching would not be done as exact string comparison, but by >> testing the inclusion of the first argument value in the service type of >> discovered services. > May I suggest "any:" - "look for the xxx service using any discovery mechanism", in the same manner that the upnp/zeroconf prefixes mean "look for the xxx service using upnp/zeroconf discovery mechanism". The current API already allows the developer to search for multiple UPnP and Zeroconf service types simultaneously. e.g. navigator.getNetworkServices([ "upnp:urn:DOMAIN:service:COMMONFRAGMENT:1", "zeroconf:_COMMONFRAGMENT._tcp.local." ]); Conflating both discovery mechanisms ignores the underlying issue that each of these service types will almost certainly provide different API messaging types. To begin with, one will be XML-based and the other _may_ be JSON based...or Protocol Buffer based or key/value based. There are also no requirements for the Zeroconf API to match the actions provided by a UPnP API that shares the same fragment name. Their sharing the same name may be purely coincidental. Furthermore, the 'DOMAIN' value in a UPnP Service Type allows two UPnP services with the same 'COMMONFRAGMENT' part to behave in completely different ways. At best, the developer would need to check the type of each returned NetworkService object against a well-known list of supported types in their web app. If that's the case then it would be much cleaner to have to call them explicitly, up-front, as the API currently allows. At worst, the developer will try to communicate with each returned NetworkService object in the same way, using a common API, which UPnP/Zeroconf services never share. What is intended to be a convenience feature here turns out to be quite ambiguous in my opinion. br/ Rich > [DAP-ISSUE-131] http://www.w3.org/2009/dap/track/issues/131
Received on Saturday, 20 July 2013 00:12:36 UTC