[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Darin Fisher]

On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu <andreip at google.com> wrote:

> 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.
>
>
That's a good point.

I guess I feel less strongly about orientation events, especially since
there is such a large continuum of states.  Whereas with battery state,
there are fewer states and less frequent changes.

navigator.onLine and the online/offline events are somewhat comparable
to battery state in my opinion.  Both change at a relatively low frequency.

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