[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Eric Seidel]

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