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

RE: Device light and proximity sensor

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Wed, 9 May 2012 19:18:41 +0000
To: Doug Turner <dougt@mozilla.com>
CC: Niklas Widell <niklas.widell@ericsson.com>, Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C350FEAD13A@WABOTH9MSGUSR8D.ITServices.sbc.com>
I will definitely do that, as example "how to use this" code, when the spec is updated to include the features. 

I can imagine ways to mock up such capabilities, but they are IMO an unnecessary overhead (I know overhead cuts multiple ways). 

For example, if I don't know the event rate I can have a callback that collects and averages all events over my desired event rate interval, or remembers only the last event value. When the interval expires (a timer is needed for that) I can invoke whatever code I want to handle my rate-limited events.

If I don't know the trigger points, I can similarly have a callback that tests the received events and ignores those that don't qualify.

But in both cases, my main concern is the delivery of superfluous events, which I believe would cost in terms of CPU battery etc (I don't have actual test results to validate that assertion).

Thanks,
Bryan Sullivan 

-----Original Message-----
From: Doug Turner [mailto:dougt@mozilla.com] 
Sent: Wednesday, May 09, 2012 7:46 AM
To: SULLIVAN, BRYAN L
Cc: Niklas Widell; Robin Berjon; public-device-apis@w3.org public-device-apis@w3.org
Subject: Re: Device light and proximity sensor


On May 9, 2012, at 7:40 AM, SULLIVAN, BRYAN L wrote:

> On the DAP call today I mentioned some thing related to this, and Dzung's update to the Sensor spec in response to Doug's spec. Overall, my goal is that we get specs to CR with at least the minimum functionality that developers need to build effective apps. The one/many spec debate has been had before, and I will remain on the sideline there (ere are valid points on both sides).

Agreed.

> I'm more concerned that the Sensor APIs contain the essential functionality. I'm not yet convinced that a simple min/max response for the ambient sound/light and proximity sensors will be enough, ie that no information/control of trigger points and event rate is needed. But I can be convinced if someone can explain how a Web developer would deal with such issues in an efficient, cross-platform way in the case that platforms vary widely in these additional aspects.

Turn this around Bryan.  Explain why you think that trigger points or an event rate is needed.  Show, with an example for bonus points :) , how an application would be that much better if such apis exists.  My claim is you don't -- you have minimum functionality to build effective apps.

Doug
Received on Wednesday, 9 May 2012 19:19:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 19:19:47 GMT