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 Thursday, 3 February 2011 16:49:15 UTC