Re: web intents version of sensor api

Pl. find my comments in-line.

Balaji N V
Samsung



From: Charles Pritchard 
Sent: Monday, March 26, 2012 1:48 PM
To: JOSE MANUEL CANTERA FONSECA 
Cc: Carr, Wayne ; public-device-apis@w3.org 
Subject: Re: web intents version of sensor api


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

Using web intents (whose primary job is to discover the provider of a given service) for getting sensor data or any such device API seems to be a complex approach. Even if we go about doing this, sensor data formats, request and response behavior should be defined. Please correct me, if I am wrong.


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

Could you please point to the URL explaining this scenario in detail (sorry if it is already shared. I did not attend the F2F). I am wondering the performance impact of wrapping the sensor APIs inside web intents. Do you have any PoC or actual implementation that helps understanding the performance impact?


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