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

Re: web intents version of sensor api

From: Doug Turner <dougt@mozilla.com>
Date: Sat, 24 Mar 2012 09:43:59 -0700
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <0E994EE3-952D-43DD-9E19-57065FAD7D0A@mozilla.com>
To: "Carr, Wayne" <wayne.carr@intel.com>
I am not a believer. -1.

On Mar 24, 2012, at 9:36 AM, Carr, Wayne wrote:

> Before dropping the sensor API I think it would be useful to consider what a sensor API spec would look like if changed to using WebIntents.  Does the WG really want 7 different drafts for these sensor types that would all be virtually identical?
> This is very informally sketched out just to show the general idea.  It seems very straightforward using webintents, but something does have to specify what the formats are.
> Definitions:
> * GetSensorData – one shot request to get a value.
> * WatchSendorData – sets up stream of data from sensor.  Can ask for data only when trigger points are crossed or instead periodic reports but no more frequently than some interval.
> **** fields for the webintents constructor for the request ****
> Actions (one of these):
> http://www.webintents.org/GetSensorData
> http://www.webintents.org/WatchSensorData
> Or “w3.org” instead of “webintents.org”
> type (one of these):
> http://w3.org/sensors/AmbientTemperature/
> http://w3.org/sensors/AtmPressure/
> http://w3.org/sensors/RelHumidity/
> http://w3.org/sensors/AmbientLight/
> http://w3.org/sensors/AmbientNoise/
> http://w3.org/sensors/DevProximity/
> http://w3.org/sensors/DevMagneticField/
> function is passed for OnSuccess return data
> For http://www.webintents.org/WatchSensorData only,
> a message channel port is passed to the service in the intent request. 
> In extraData the following can be passed [optional]
> ReportInterval= string containing a double value – requests service to send sensor data no more frequently than every ReportIntervalmilliseconds
> **** response from service to client ****
> For http://www.webintents.org/GetSensorData” response from server is sent to OnSuccess function passed when making the intents request.
> For http://www.webintents.org/WatchSensorData response is sent to the port passed to the server
> Returned Information in “data” object from sensor sent in either the OnSuccess function for a GetSensorData action or to the port for GetWatchData
> Fields in data object
> * action (one of the above or new ones from future specs)
> * type (one of the above or new ones from future specs)
> * double minInRange – minimum value in sensor range
> * double maxInRange – maximum value in sensor range
> * string name – if the sensor has some friendly name for the sensor
> * value -- array in the following units of measure (typically only the first value in array is set, but array in case future devices have more than one Proximity Sensor for instance)
> http://w3.org/sensors/AmbientTemperature/  double centigrade
> http://w3.org/sensors/AtmPressure/  double kiloPascal
> http://w3.org/sensors/RelHumidity/  double percent
> http://w3.org/sensors/AmbientLight/ double Lux
> http://w3.org/sensors/AmbientNoise/ double dbA
> http://w3.org/sensors/DevProximity/ double centimeter
> http://w3.org/sensors/DevMagneticField/ objects containing double x,y,z in micro-Tesla
> **** control messages on port to service ****
> Client can send service a sensorControl object using the port – format of object sent is as follows:
> * type (one of the above or new ones from future specs)
> * command – one of the following
>       setTriggerPoint value --- where value is a single double for the sensors that return a single value and a comma separate list of doubles for DevMagneticField – can send this repeatedly for different triggers
>       removeTriggerPoint value --- same as what was set
>       setReportInterval --- double seconds to indicate reports should not be sent more frequently than this
>       stopWatchpoint – going to be closing the port
> Service responds by sending a data object echoing the same but ending with result= string “success” or “fail”

Received on Saturday, 24 March 2012 16:44:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:35 UTC