Re: Discovery API

Just to note to draw attention to the open source discovery demo I wrote 
a few months back and described on the W3C Blog, see:

http://www.w3.org/QA/2011/04/discovery_and_the_web_of_thing.html

It allows you to scan independently for services on mDNS, SSDP (i.e. for 
UPnP devices), SLP, Bluetooth and USB.

The demo uses a NPAPI plugin that exposes the following asynchronous 
methods:

    scan_mdns(obj)
    scan_ssdp(obj)
    scan_slp(obj)
    scan_bluetooth(obj)
    scan_usb(obj)

These return immediately after spawning threads that call back to the 
following methods respectively on the object passed to the scan methods:

    mdns(name, type, interface, address, port)
    ssdp(address, port, description)
    slp(description)
    bluetooth(address, name, devclass)
    usb(address, devclass, description)

The various discovery protocols can be invoked concurrently. For SSDP, 
the UPnP XML service description is obtained from the device via HTTP 
and passed up to JavaScript in the description argument. The demo maps 
the Bluetooth device class fields to human friendly names using 
javascript. The usb scan does this internally based upon the vendor and 
product identifiers using a copy of the list maintained by Stephen 
Gowdy, see:

    http://www.linux-usb.org/usb-ids.html

The next level of refinement would be a way to constrain discovery to 
filter the kinds of service within the scan itself, rather than as part 
of the JavaScript  code based upon each call back. There is also the 
question for controlling how long each scan lasts, e.g. via a timeout 
argument or a stopScan method. I would be very interested in discussing 
ideas for refining the interface for each of the discovery mechanisms, 
as well as suggestions for enabling scripts to drill down on further 
details for each service/device, prior to binding to a given service.

The demo plugin is further described at:

http://www.w3.org/2011/04/discovery.html

The service discovery plugin can be loaded as part of a JavaScript 
library either within the web page or in a separate security context 
such as a Firefox addon or Chrome extension. This latter approach is 
valuable when you want to separate trusted script code from the 
relatively untrusted script code running within a regular web page.

p.s. the plugin is currently limited to Linux, but I would be interested 
in collaborating on extending it to other platforms, as well as any 
suggestions on the code itself, which is released under the Apache 2 
license.  I am next planning on adding a mechanism for loading service 
drivers as part of the plugin for demo purposes using shared object 
libraries plus JavaScript.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett

Received on Friday, 10 June 2011 05:58:55 UTC