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

RE: CfC to change Sensor approach, not progress current draft

From: Carr, Wayne <wayne.carr@intel.com>
Date: Wed, 21 Mar 2012 18:57:35 +0000
To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <52F8A45B68FD784E8E4FEE4DA9C6E52A3E3023BB@ORSMSX101.amr.corp.intel.com>
It would be interesting to see the Web Intents approach to sensors discussed below.  Could someone post a description of that?

With Web Intents, you could pass a message channel port to get a series of updates, a very common way of using sensors.  But then you need to define a protocol for asking for watchpoints, for stopping them, for indicating how often you would like to get them, for setting values for notification when they're crossed.  You may need to be able to define the sensor in more detail than a mime type.  Those would all be the same for every sensor that produces a stream of data.  You would not want to reproduce that in every single different spec for each particular sensor.  You'd need a sensor spec containing much of what the current draft contains, wouldn't you?

For the larger picture of sensors not in a device itself but on a local network of some kind, it isn't simply indicating you're interested in say wind speed/direction sensors and getting one back.  It could be a dozen sensors in your yard and you'd like to be able to get data from all of them to summarize on a web page.  Web Intents seems more set up for getting a single response.  How do you get a set of sensors back to connect to and to know which one is which?

>-----Original Message-----
>From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
>Sent: Tuesday, March 20, 2012 9:22 PM
>To: public-device-apis@w3.org
>Cc: Frederick.Hirsch@nokia.com
>Subject: CfC to change Sensor approach, not progress current draft
>
>All:
>
>During the DAP Shenzhen F2F on 21 March 2012 we reviewed the status of the
>Sensor API work, including the current draft, which currently has no official
>standing [1].
>
>Members of the group at the meeting expressed concerns with the architectural
>approach of this document, with the number of  sensors in one document and
>inclusion of discovery as part of the draft, given that  WebIntents could be used
>for discovery. (An example was presented how temperature could be obtained
>from a sensor or a web weather service, and this could be transparent using the
>WebIntents approach, offering a benefit.)
>
>Privacy and security threat analysis might vary with the type of sensor, arguing
>for the need to analyze different sensors independently, making sure each has the
>appropriate approach.
>
>Thus the sense of the meeting participants is that the Working Group should
>discontinue work on the current Sensor API draft and instead review sensors
>independently and consider alternative approaches.
>
>This is a Call for Consensus (CfC) to formally discontinue work on the current
>Sensor API draft, to consider using WebIntents for sensor discovery, and to
>continue work on sensors in general, producing specifications specific to sensors
>as appropriate.
>
>Where CfCs are concerned, silence is considered to be assent, but positive
>support is preferred (even if simply with a +1).
>
>regards, Frederick
>
>Frederick Hirsch, Nokia
>Co-Chair, W3C DAP Working Group
>
>[1] http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/Overview.html

>
>

Received on Wednesday, 21 March 2012 18:58:10 UTC

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