Re: web intents version of sensor api

It's a draft in an attempt to salvage and/or reframe the current work.

Consider that the sensor may be detached from the host. There's an example on the web of using websockets to get a mobile gyroscope to control directional movement on the screen.

I do think some of the intents serialization is long-winded, but I wouldn't claim over-engineered.

A mechanism for transporting sensor data over intents is useful. 

-Charles




On Mar 26, 2012, at 12:12 AM, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es> wrote:

> It seems this is a rebranding of the genuine Sensor API making things unnatural and over-engineered. -1. I'm not a believer. 
> 
> De: "Carr, Wayne" <wayne.carr@intel.com>
> Fecha: Sat, 24 Mar 2012 17:36:00 +0100
> Para: "public-device-apis@w3.org" <public-device-apis@w3.org>
> Asunto: web intents version of sensor api
> 
> 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”
>  
>  
> 
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx