W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2013

[discovery]request by web app developers

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Date: Mon, 22 Apr 2013 17:54:51 +0900
Message-ID: <5174FADB.7040600@telecom-paristech.fr>
To: public-device-apis@w3.org
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

-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Monday, 22 April 2013 08:55:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC