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 Monday, 26 March 2012 23:56:11 UTC