Re: web intents version of sensor api

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”
>  
>