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

Re: web intents version of sensor api

From: Doug Turner <doug.turner@gmail.com>
Date: Mon, 26 Mar 2012 11:05:57 -0700
Message-ID: <CAHni0v8Xs8gX7_=014iyGvTapBNSYiVk1K0aRBRo_u0J1hM1oA@mail.gmail.com>
To: "Carr, Wayne" <wayne.carr@intel.com>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC