[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Eric Seidel]

Given how many desktop applications do this, I think we're well off
into the land of wishes and fairy tales. :)

But it's also possible that libraries like jquery or Google's closure
could do this... but again, I'm skeptical.  Then again, if we don't
expose information like this, they don't ever have a chance to prove
me wrong.

-eric

On Fri, Jun 17, 2011 at 10:54 AM, Darin Fisher <darin at chromium.org> wrote:
> I think there are web app developers that would do things differently if
> they
> knew their user was running on battery power.  An app might scale back its
> CPU usage, or run a timer at a lower frequency.  Crazy idea: Maybe an
> advertising network could be "nice" and not show animated ads to such
> users? ;-)
> -Darin
>
> On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel <eric at webkit.org> wrote:
>>
>> My 2¢:
>>
>> I'm confused by who the client of this API would be.
>>
>> It seems that "web sites" don't really need to know my battery state.
>> But "web applications" that are on mobile phone (like WebOS, or
>> Apple's original vision for iPhone apps) would want battery state
>> information, but would want *more* information than this spec provides
>> (imagine trying to write any power-management application like the
>> zillion examples available for Apple's Dashboard, or iPhone).
>>
>> I'm also not sure that I want all web sites knowing this information.
>> I wonder what fingerprinting vectors this API would expose (if any?).
>> Certainly websites could know if their visitors are laptop users or
>> not (but I suspect they can already figure that out from screen size
>> and UA strings).
>>
>> It's also possible that I'm just spreading FUD here, and that smarter
>> people than I have already hashed this all out on the spec list...
>>
>> -eric
>>
>> On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher <darin at chromium.org> wrote:
>> >
>> >
>> > 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
>> >
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>