DAP-ISSUE-130: Enable variety of protocols (e.g. UPnP, Bonour) with protocol independent developer code [Network Service Discovery]

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