[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Robin Berjon]

Hi,

some belated additional thoughts on this thread.

On Wed Jun 15 02:41:01 PDT 2011 Holger Freyther wrote:
> I am not participating in any W3C group so this might or might have been
> discussed but this specification seems to be over simplified, specially if you
> compare it what is provided by the power supply class of the Linux kernel

The specification is intentionally simple. Aside from the fact that simple is good in itself, this simplicity derives from both use cases and implementability considerations. There are essentially two use cases:

    • The battery is low, decide to be a good citizen (hit the network less often, simplify or remove UI animations).
    • The battery is critically low, commit all unsaved changes immediately, warn peers (e.g. in a chat) that this node is about to vanish.

As for implementability, there's an awful lot of variance between what sort of power management a device can perform, and just as much variance in how it us exposed in system APIs. Addressing the full breadth of these is possible, but it doesn't seem worth it when you consider web-related use cases.


On Wed Jun 15 10:25:05 PDT 2011 Greg Simon wrote:
> From what I can tell the spec offers no way for the web application to
> initialize any algorithm based on the battery/power state because there is
> no guarantee of "minimum time" when a new document is created and the first
> battery event arrives. Ideally there would be a way to "kick" the UA into
> sending the battery event on demand.


Unlike the device orientation event where you may want to immediately create your UI and therefore not want to wait the few milliseconds it takes to get the information (because the user will see the flicker), I don't think a similar situation arises with the battery level. Given that the event essentially fires as soon as possible after listener registration, if you're deciding to trigger some costly computation (e.g. a synch operation over lots of data) based on whether there's enough battery or not we're talking about a situation in which you won't find yourself performing massive UI changes in response, and at most a few milliseconds' delay. All in all, I don't think that's a big deal.

The only case I can think of in which this may affect a user's perception is if you're displaying a battery gauge. Not the sexiest use case around, and even if you're doing that there's nothing wrong with drawing your gauge grey at first and updating it when the data comes in. It will look quite normal.


On Thu Jun 16 09:02:29 PDT 2011 Darin Fisher wrote:
> 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.


I'll leave aside device orientation for which I can certainly agree with the issue you raise, but which is handled by another group (I encourage you to send them feedback if you have already though). Do you have a use case in mind where drawing the UI would immediately and massively depend on the battery level?


On Fri Jun 17 10:47:47 PDT 2011 Eric Seidel wrote:
> I'm confused by who the client of this API would be.

That's okay, it is not uncommon :) We've become so used to the notion that web browsers could only talk to web servers that interfacing them to other things, what's more in a web-compatible manner, is often confusing (many are still befuddled as to why we created three separate file APIs for reading, writing, and FS). But there's good stuff to be made here.

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

A power-management app is pretty much a non-use case for this API (and, in general, the "manage everything for this aspect" use case is a non-starter for device APIs: they require exposing too much information that it almost never used, and open up way too many privacy/security concerns).

We tend to not make any web site/web app distinction. Sure, if you're only showing pictures of kittens, you probably don't need to know the battery level (I hope I'm not going to regret saying that), but then you probably don't need anything much beyond HTML/CSS. If you have an application however, irrespective of whether it's a web site running in the browser or a web component wrapped inside some native bacon, then the use cases cited above exist.

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

The DAP WG is always extremely sensitive to fingerprinting issues, and it's been discussed for battery. As far as we can tell, given the information currently exposed, it doesn't make things measurably worse than they already are (you could measure the speed at which a battery empties or charges and use that as identifying information, but there's a lot of information you're going to get much more easily that will tell you a lot more). If we did however expose more information as you suggest above (number of batteries, UPS availability, battery make, model, and serial number) then fingerprinting would indeed be a concern. That's one of the reasons (if any are needed atop the lack of use cases and increased implementation cost) why we think that a simpler API is better.

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

I don't think people on the spec list are smarter than you are, but we've indeed hashed these things out. You're welcome to join :)

> But it's also possible that libraries like jquery or Google's closure
> could [change their processing based on battery level]...
> but again, I'm skeptical.

I've been thinking along similar lines, and I'm not so skeptical. It's certainly unlikely that every other web site out there is going to start monitoring battery levels and optimise for low conditions, but in a world in which the app you write (and by app I mean in the broad sense that very much includes web sites) is in competition with apps written by several million other developers, attention to small details like being power-conscious make a difference. Also, it would be rather trivial for jQuery/jQuery UI/jQuery mobile (and of course any other library) to keep track of the battery level and kill UI animations and other such things below a certain level. That would bring good practices to many, at little cost. I sure wish my phone did that.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon