W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2011

Re: Battery Status Event Spec

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Mon, 11 Apr 2011 15:59:09 +0300
CC: "public-device-apis@w3.org Group WG" <public-device-apis@w3.org>
Message-ID: <D2455F1A-C3E2-4BFB-B822-C2AFE96AB556@nokia.com>
To: ext Rich Tibbett <richt@opera.com>
Hi,

On 8.4.2011, at 13.59, ext Rich Tibbett wrote:

> The only absolutely locked-in, useful use case I see is the following:
> 
> if(event.level > 20) {
>  // No problem!
> } else {
>  // you're running on low battery so we'll disable the
>  // power-hungry feature z to save the battery
>  // (of course, you can enable z manually if you wish)
>  // + we'll step up the automatic saving of your ongoing
>  // session just in case your machine dies mid-sentence.
> }
> 
> Every other method or property is negotiable. I don't see the need to know which power source I'm currently connected to hence the proposal to remove isBattery and isCharging. In fact, I could infer that I'm connected to the wall if I don't receive any subsequent callbacks after an initial power source event has been fired (with event.level = 100).
> 
> Furthermore, it should be easy to produce a timeRemaining guesstimate based on event callbacks that don't contain this data. As an example, if an event starts at time t and I receive an event.level = 99 at t+180 seconds and then an event.level = 98 at t+120 seconds and then an event.level = 97 at t+120 seconds I can make a guesstimate, via Javascript, that at time t+420 the machine is likely to remain responsive for the next 3 hours and 12 minutes at current battery consumption levels. There's little need to provide that data (and have two separate power level attributes) in the returned event itself.
> 
> Based on that, I'd propose to also drop the timeRemaining attribute, leaving only the 'level' attribute in an event callback.

Thanks again for the feedback. I added a note to the spec that the inclusion of those properties (isBattery, isCharging, and timeRemaining) is under consideration.

> Dzung's proposal to rename the event to PowerSourceEvent also makes a lot of sense for this also.


I did not yet rename the event as I believe that the BatteryStatusEvent more concretely conveys the meaning than the PowerSourceEvent and maps to the spec name. "Power Source Event Specification" sounds a bit too abstract to me. That said, lets bikeshed the naming once we have all the hard problems solved -- if that's fine with you guys :)

-Anssi
Received on Monday, 11 April 2011 12:59:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:20 GMT