Re: web intents version of sensor api

We will not use WebIntents to expose sensor data.  It is overly
complex and isn't consistent with other content APIs.

Doug Turner

On Mon, Mar 26, 2012 at 10:45 AM, Carr, Wayne <wayne.carr@intel.com> wrote:
> I’ll gather the comments so far and respond to them here rather than a
> series of responses with a  suggestion at the end.
>
>
>
> - comments that WebIntents should only interact with another web page/app so
> wouldn’t have this data.
>
> The current WebIntents draft says: “A Service is a web page which can handle
> an Intent, possibly returning a piece of data to the calling Client page.
> Again, the User Agent may have ways to deliver Intents to Services which are
> not web pages. These may be extension APIs, plug-in helpers, external OS
> handlers, etc.”   So WebIntents are intended to handle this sort of thing,
> provided by the UA – it isn’t just to Web Pages that don’t have any special
> privileges.  Web Intents can be a very nice way to ask for limited
> capability to restrict how much permission you’re asking for with the UA
> providing the service.
>
>
>
> - that WebIntents is needlessly overarchitecting this and that it would be
> better to do this directly rather than WebIntents
>
> I agree.  But one of the primary reasons of killing the sensor API draft was
> that people thought WebIntents chould be used.  Instead of passing the
> request below to activating a WebIntent, pass it to a SensorManager object
> the UA provides.  The SensorManager would do the same request to the user to
> get permission to expose this data as WebIntents would.  So the proposal
> with a minor change, does it directly instead of using WebIntents.  That’s
> what I would prefer.  (but if the WG wants WebIntents …)
>
>
>
> - on WebIntents should be able to provide a web socket instead of a message
> channel port so the service wouldn’t have to be provided locally
>
> That’s a more general suggestion for the WebIntents task force I think.  It
> isn’t relevant to the sensor api since this is about access to sensors very
> commonly on the device (just like orientation, location, etc.).
>
>
>
> - On wanting 7 separate specs instead of one.
>
> Looking at what is below in the proposal, those 7 specs would be nearly
> identical in the best case.  In the worst case, it would be 7 needlessly
> different ways of doing the same thing.  Getting temperature vs getting
> humidity vs getting atmospheric pressure.  Those are very similar things. It
> should be one spec.
>
>
>
> I don’t think the WG should kill the sensor API draft.  I think it should
> instruct the editors to simplify it using Bryan’s edit as the starting point
> (and a SensorManager) object as above – or if the WG wants WebIntents to
> tell the editors to go that way.  But not kill the draft altogether.
>
>
>
> From: Carr, Wayne [mailto:wayne.carr@intel.com]
>
> Sent: Saturday, March 24, 2012 9:36 AM
> To: public-device-apis@w3.org
> Subject: 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”
>
>
>
>

Received on Monday, 26 March 2012 18:06:29 UTC