[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen <
anssi.kostiainen at nokia.com> wrote:

> 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
>
> ]]
>

The proposal wasn't to make blocking APIs that query any devices.  Instead,
you would be able to get synchronous access to the last known value for a
device property ("last known battery state", "last known device
orientation", etc.).  In particular, you would get access to the last known
value prior to your page being loaded.

Synchronous access to this value seems helpful for the reasons stated in
this thread.  But, let me expand on that for a moment.  Suppose an
application wanted to know both the battery state and the device orientation
before generating its content.  It would need to asynchronously query both
states before proceeding.  That seems quite awkward, especially when the
information could be provided synchronously.



>
> > 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.
>

Do we have experience showing that such polling abuse is a problem caused by
document.readyState?  I think that people would write setInterval based
polling code if there were no convenient event subscription API.  But, the
proposal is to provide both, just as both are provided for page load
progress information.

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110617/3f410233/attachment.html>