[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Andrei Popescu]

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

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.


Thanks,
Andrei