- 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
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 implementations. -- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Thursday, 10 March 2011 14:43:07 UTC