W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2011

Re: Potential charter item: mDNS/DNS-SD

From: Dave Raggett <dsr@w3.org>
Date: Thu, 10 Mar 2011 14:42:39 +0000
To: Robin Berjon <robin@berjon.com>
Cc: Thomas Roessler <tlr@w3.org>, public-device-apis@w3.org
Message-ID: <1299768159.19248.53.camel@ivy>
On Thu, 2011-03-10 at 14:07 +0100, Robin Berjon wrote:
> On Mar 10, 2011, at 12:34 , Dave Raggett wrote:
> > This is an active area of work for the European FP7 project "webinos" of
> > which W3C/ERCIM is a part. We are looking at ways to enable discovery
> > over a variety of interconnect technologies e.g IP networks (mDNS, SSDP,
> > SLP), USB, Firewire, Bluetooth, Zigbee, and by context (social network
> > connections and smart spaces). 
> > 
> > The bottom line is that if device discovery is part of the DAP charter,
> > we will be able to contribute specifications and hands on implementation
> > experience as well as to help with editing WDs.
> It would certainly be very interesting to hear Webinos's perspective
> on this, and if it means more participation and help implementing then
> so much the better!
> In chartering terms, we need however to be strict about scope and to
> have a good idea of what kind of specification we're heading towards.
> Could you provide more detail?

If we look at local discovery, then we are talking about APIs that
allows web page scripts to enumerate the available devices subject to
some constraints, e.g. what printers are there that can be reached via
one of the interconnect technologies attached to this device. The API
may also allow you to ask for a device by name, e.g. using a name that
was previously assigned to the device.

One challenge is that each discovery mechanism and interconnect
technology has its own vocabulary. This suggests the need for lower
level APIs specific to a given mechanism, e.g. one for mDNS, another for
SSDP, another for USB and so forth. The discovery process may take a few
seconds, as for Bluetooth, or be very quick as for USB. An asynchronous
API would cater for both. It may also be possible to register event
listeners for when a matching device is plugged in, or unplugged.

A higher level API is feasible using a common vocabulary that hides the
low level details. This could be provided by a JavaScript library and
standardized later.

One implementation strategy we are looking into is to use XHR or
websockets to communicate with a local server. Another, is the use of a
cross browser NPAPI plugin that embeds a JavaScript engine (e.g. V8)
together with a mechanism to load native libraries on demand. This could
be combined with conventional browser extensions (e.g. Firefox add on,
or Chrome extension) to present a high level API to web page scripts. A
further option is to directly extend the browser code base.

How much detail do you need for the charter?

> > See http://webinos.org/ for more details.
> There isn't much on the site. A few months back I sent an email to "be
> part of it" as it says but apart from finding a familiar face at the
> other end I've never heard back L)

The first round of API specs are due mid 2011 and the project will then
have a further two years to refine these and the associated

 Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Thursday, 10 March 2011 14:43:07 UTC

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