[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
andreip at google.com
Fri Jun 17 10:27:08 PDT 2011
On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher <darin at chromium.org> wrote:
> On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> <anssi.kostiainen at nokia.com> wrote:
>> 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.
> 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.
In the case of device orientation, having such a synchronous property
would probably mean having the UA do a lot of wasted work, constantly
exercising the underlying hardware just in case some Web app might
need this information at start-up. However, I think it's reasonable to
expect that Web apps using this API will be built in such a way that
they will do work in response to orientation changes, so it's perhaps
natural for them to treat the initial orientation the same way.
More information about the webkit-dev