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

RE: web intents version of sensor api

From: Doug Turner <dougt@mozilla.com>
Date: Mon, 26 Mar 2012 23:58:06 -0700 (PDT)
Message-ID: <iyjl801wpnimbmek1lqj58rw.1332831408517@email.android.com>
To: roBman@mob-labs.com
Cc: BRYAN L SULLIVAN <bs3131@att.com>, Wayne Carr <wayne.carr@intel.com>, Marcos Caceres <w3c@marcosc.com>, jeanfrancois.moy@orange.com, mounir@lamouri.fr, public-device-apis@w3.org
Can the editor or chair step in?  The back and forth over this issue is less than useful.

Rob Manson <roBman@mob-labs.com> wrote:

+1  Nicely put 8)


On Tue, 2012-03-27 at 06:06 +0000, SULLIVAN, BRYAN L wrote:
> I would like to see a JS API for the directness and simplicity of it, for device-local sensors (as compared to needing to discover a helper webapp that can access the sensors).
> But I also see the usefulness of a helper webapp accessed through Web Intents, providing a bridge to sensors that are accessed through some other device e.g. on a local network. Such devices can provide a gateway service to the (likely) non-HTTP interfaces (or proprietary networking in general) of some sensors, and also allow the sensor owner to manage access rights/privacy etc.
> In general I think we are seeing realization that equivalent APIs/resources can be local or remote. I don’t think however we need one API (or API architectural style) to rule them all.
> Thanks,
> Bryan Sullivan 
> -----Original Message-----
> From: Carr, Wayne [mailto:wayne.carr@intel.com] 
> Sent: Monday, March 26, 2012 4:56 PM
> To: Marcos Caceres
> Cc: jeanfrancois.moy@orange.com; mounir@lamouri.fr; public-device-apis@w3.org
> Subject: RE: web intents version of sensor api
> It seemed in the responses to this, it was pretty clear that people thought the Web Intents approach is over engineered for the purpose of just exposing known, common sensors on the device.  I think it's also the case that a classic API for each of the 7 would be identical specs with a few lines different.
> I think where we should go with this is a typical JS API built on the modifications that Bryan did and passing the object to a SensorManager object instead of Web Intents.
> >-----Original Message-----
> >From: Marcos Caceres [mailto:w3c@marcosc.com]
> >Sent: Monday, March 26, 2012 4:03 PM
> >To: Carr, Wayne
> >Cc: jeanfrancois.moy@orange.com; mounir@lamouri.fr; public-device-
> >apis@w3.org
> >Subject: Re: web intents version of sensor api
> >
> >
> >
> >
> >On Monday, 26 March 2012 at 23:02, Carr, Wayne wrote:
> >
> >> This isn't relevant to the topic of this thread - the dap sensor api - since clearly
> >the feedback is that the WG would rather have a direct api and doesn't want to
> >use web intents.
> >>
> >> But the webintents taskforce is enabling more general use of webintents than
> >simply sandboxed app to sandboxed app. The UA or UA/extension can provide
> >the service end. They're looking at use cases that can do things like send
> >commands to devices on local networks. E.g. turn on a light or control a vcr. So
> >services are not limited to what can already be done in a web app.
> >>
> >
> >
> >It's been good to see both sides of the coin. It might be an issue that the use
> >cases for this API are not clear. Maybe we need to go back there and then see if
> >we arrive at a Web Intents solution or a more classical JavaScript API solution.
Received on Tuesday, 27 March 2012 06:58:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:35 UTC