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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
