[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Anssi Kostiainen]

Hi,

On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> 
> On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen <anssi.kostiainen at nokia.com> wrote:
> 
> On 15.6.2011, at 21.29, ext Darin Fisher wrote:
> 
> > There should probably be a way to poll the current state.  Much as you can poll the document.readyState and respond to progress events, it would seem to make sense to have a way to poll the battery state as well as respond to battery state change events.
> 
> The current design is quite similar to that of the Device Orientation Event. We discussed the polling option but settled on the current design. Let me know if you'd like me to dig into archives for some pointers on that design decision.
> 
> I'd be curious to read them.  Off-hand it seems like device orientation suffers from the same problem.  You wouldn't want the application to do too much work that would be discarded once it finds out that the orientation is X instead of Y.

I think the design guidelines introduced in the following Mozilla position paper are still valid. In this context, specifically:

[[

Device APIs should be asynchronous; in particular, user agents should not have to block on return values of Device API function calls, and Device APIs should be driven by callbacks.

  http://www.w3.org/2008/security-ws/papers/mozilla.html#asynchronous

]]

> It seems like this is information that we have available immediately, and it is a bit unfortunate that page authors need to delay initialization until they receive the initial orientation or battery status event.

In addition to the above mentioned reason, a synchronous API might encourage web authors to write badly performing code, i.e. poll the battery status via setInterval() too often. In the current event-driven design a new event is dispatched only when the battery status changes.

-Anssi