- From: Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org>
- Date: Tue, 09 Jul 2013 17:19:42 +0000
- To: public-device-apis@w3.org
DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code [Network Service Discovery] http://www.w3.org/2009/dap/track/issues/130 Raised by: Jean-Claude Dufourd On product: Network Service Discovery Dear all, As I told you before, I have an implementation of NSD for UPnP and Bonjour, with extensions for exposing a service and communicating between webapp and service. Note: In Bonjour, exposing a service means providing a JSON service description (à la SDCP), and sending messages means exchanging JSON messages over plain text sockets. By doing this, I have exactly the same level of functionality in UPnP and Bonjour. And thus, my first service developer's first strong request was "please get rid of anything protocol specific". He wanted to specify a service type (whether in a search or in an advertizing request) in a way that can be transparently implemented in UPnP or Bonjour, depending on what is implemented. This assumes that some implementations will have UPnP and Bonjour, and others will have only one of the two, and he wants the same webapp to simply address all cases. I tried to implement this by specifying only the main COMMONFRAGMENT of a service type. In UPnP, a service type is "upnp:urn:DOMAIN:service:COMMONFRAGMENT:1" (note: I chose my project name for DOMAIN) In Bonjour, a service type is "zeroconf:_COMMONFRAGMENT._tcp.local." I first attempted to implement the search for COMMONFRAGMENT on top of my NSD implementation. It was not possible. I had to modify/extend the NSD implementation. By doing this, I do not remove the difference of NSD response between UPnP and Bonjour, but the author's code can then be made protocol-independent. And I think that is a "good thing". 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. If the absence of a prefix is a problem to anyone, using a prefix of "fragment:" would also work. What do you think ? Best regards JC
Received on Tuesday, 9 July 2013 17:19:43 UTC