Access to sensors, actuators, etc (was: RE: Rechartering Device APIs & Policy Working Group)

Thanks for your reply Robin,

Yes, I agree that a complete concept of access to "things" located "anywhere" is a fuzzy, or rather huge, area. This has to be addressed elsewhere (I am not really familiar with earlier W3C activities on "Web of Things").

So we may have to start with the basics. The existing extensible sensor API in "The System Information API" is probably ok for some use cases but too limited for others. Other proposals for generic sensor APIs, e.g. http://bondi.omtp.org/1.5/pwd-1/sensor.htm#::sensor::SensorCapabilities,  seem rather similar. Take my blood glucose meter (BGM) as a simple example. I could specify a "BGM" property but my BGM delivers an array of measurements where each measurement consists of blood glucose value, time/date and notes. Furthermore I want an application be able to configure and set preferences in the BGM. So, the simple structure of the sensor API in "The System Information API", where I can only retrieve and monitor single values, does not work in this case. We need something more flexible.

So...

1. Should we start by lifting the web application environment to the same level as native application environments? For example, in Android we have Bluetooth and NFC APIs. Should we start by specifying similar low level "socket" connectivity APIs for web applications? We could then let sensor/actuator/accessory vendors provide applications and "easy to use" JS libraries for web developers tailored to their specific devices. 

2. Another approach is to build something based on the Web Introducer. There is already "The Bookmark Introducer", which is an example of a specific API build on top of the Web Introducer. Could we build different "Introducer" APIs for different types of resources? For example, a "BGM Introducer", a "Heart rate monitor Introducer", etc. Or is this too farfetched? Furthermore, we would probably need low level APIs, according to 1, anyway in order to facilitate creation of resource providers for local resources in order to avoid native coding. 

However, most important is that what is specified really gets implemented. Which is the view on this issue of the major browser vendors?

Best regards
   Claes




> -----Original Message-----
> From: Robin Berjon [mailto:robin@berjon.com]
> Sent: den 3 februari 2011 17:49
> To: Nilsson, Claes1
> Cc: Dominique Hazael-Massieux; public-device-apis; Isberg, Anders; Nord,
> Christian; Svensson, Magnus
> Subject: Re: Rechartering Device APIs & Policy Working Group
> 
> Hi Claes,
> 
> On Feb 3, 2011, at 15:38 , Nilsson, Claes1 wrote:
> > Generally I think that the charter looks good. To me it sounds
> logical to separate out work on a policy framework from DAP. It is
> architecturally independent of the APIs and requires another kind of
> competence than work on APIs.
> 
> Glad to hear your opinion on this, I must say that I can only agree.
> 
> > Another question is the WG's view on "a generic sensor API" that is
> stated as "Future Work" in the current charter. Some options for
> sensors are for example:
> >
> > * Consider it enough with the sensor APIs defined in the System
> Information API, http://dev.w3.org/2009/dap/system-info/#sensors.
> Adding new, vendor specific, sensors is done through the extensibility
> method in http://dev.w3.org/2009/dap/system-info/#extensibility.
> >
> > * Create something more generic. See for example
> http://lists.w3.org/Archives/Public/public-device-
> apis/2009Oct/0186.html
> >
> > * Build a sensor discovery/selection mechanism / API on top of Web
> Introducer, http://web-send.org/
> 
> I am not entirely convinced that the API outlined by Dzung is all that
> much more generic. It does provide for some level of discovery, but I
> tend to think that that should be available through the basic API (if
> you ask to get or monitor something that isn't available you get an
> INFORMATION_UNAVAILABLE error).
> 
> I do think that it would be interesting to pause for a second and think
> about what may be missing here, if anything. Part of what's not in
> SysInfo is configuring and manipulating the sensors. Do we need
> something specific? I would tend to think that something like Web
> Introducer could be enough to do the job, but I'd like to hear broader
> input on this.
> 
> > DAP has so far concentrated on "easy to use" "hardwired" APIs but the
> number of sensors, actuators, "things" located in the device, in the
> proximity of the device or anywhere in the cloud that web applications
> want to access is increasing. Is this something DAP should address or
> is this a task for another WG?
> 
> I sort of understand the question, but at the same time I'm not sure I
> see its exact ramifications. I think that DAP should stick to what's
> generic so as to support the One Web vision. This doesn't mean that we
> shouldn't take specific uses into account - quite the contrary, we
> should try to be both usable and useful everywhere. But there's a fine
> (and at times difficult) balance to strike between what would be cool
> to support and what might in practice in the foreseeable future
> actually be supported. For me the cloud is a very fuzzy thing, so
> you're mentioning fuzzy access to a fuzzy list through fuzzy means ;)
> I'm not at all saying that that's bad, but I'd like to hear some
> concrete examples of what you have in mind. Talking to your sneakers
> about how much you ran over DLNA? Or using your camera from your
> computer? Or monitoring some important health indicators through your
> phone? I'm not really joking: there are two things  that we need to get
> absolutely right for this charter. One is that every deliverable must
> be clearly scoped so that everyone goes in agreeing clearly to the work
> - that's important for IP reasons but also to make sure that the group
> can be cohesive in its goals; the other is that we need to make sure
> that all our goals are clearly and unambiguously "One Web" compatible.
> That's always been implied since it's the W3C's mission, but people
> both inside and outside the group sometimes seem to believe otherwise.
> But long ramble short: I think you ask an interesting question, I'd
> like to see more concrete input on it (from you and others).
> 
> > P.S. Sorry for not responding to Robin's question on my Web
> Introducer prototyping at the last DAP call. Actually I did answer but
> I was on mute, which I didn't discover until it was too late :-) Anyway,
> I think that my mail talks for itself:
> http://lists.w3.org/Archives/Public/public-device-
> apis/2011Jan/0096.html
> 
> Don't worry, I was just asking in case you had anything to report
> because I think that's something that should be on the group's radar :)
> 
> --
> Robin Berjon - http://berjon.com/
> 
>

Received on Monday, 7 February 2011 13:57:39 UTC