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

Re: Battery Status Event Spec

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Wed, 30 Mar 2011 20:03:25 +0300
CC: "public-device-apis@w3.org Group WG" <public-device-apis@w3.org>
Message-ID: <8C1E8C0F-FEA1-4143-8FEA-9F28FE2E3A95@nokia.com>
To: "ext Tran, Dzung D" <dzung.d.tran@intel.com>

On 30.3.2011, at 18.23, ext Tran, Dzung D wrote:

> As I reviewed the SysInfo APIs section on battery status, since I was the editor for this and I don't see much differences here. I rather that we just start with what we have in the SysInfo APIs. I could do this easily for this and all the others into mini specs.

My proposal was to take the Power properties of SysInfo API as a starting point (because they're probably fairly well thought out) but apply them to the DOM Events -based model instead. The main benefits of the DOM Events-based model are re-usability and better integration to the web platform. This means we have to do some re-thinking, and we can not just simply split the existing spec into smaller pieces and be done with it.

We reviewed the proposed Battery Status Event spec during today's call and concluded it's good enough for an Editor's Draft. Here's a list of changes that we agreed to do:

1) Guarantee that the callback is triggered immediately upon handler registration.

Resolution: Add prose to make this a MUST.

2) BatteryStatusEvent should not be limited to applying to window.

Resolution: Allow any object to implement the BatteryStatusEvent interface. E.g. if AcmeCamera has its own battery that we may want to monitor separately: AcmeCamera implements BatteryStatusEvent.

3) If there's a change in battery status, what is the granularity of a change?

Proposal: Come up with a reasonable default that is good enough for all the Power properties. The timeRemaining and isCharging properties are probably the ones requiring the finest granularity. Perhaps the resolution of say 1000 ms would be enough for all the Power properties for majority of the high value use cases? I propose we align with the model used by the DeviceOrientation and add an interval attribute to the BatteryStatusEvent: "The event must fire at regular intervals and the interval must be reported, in milliseconds, using the interval attribute of the BatteryStatusEvent object."

I volunteered to create an Editor's Draft based on my initial input and factor in the above changes. Are you ok with me proceeding with that? I'm fine if you want to proceed with editing the remaining parts of the SysInfo API. Also, if you want to co-edit the Battery Status let me know so that we can coordinate.

Received on Wednesday, 30 March 2011 17:04:40 UTC

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