Hi, On 16.6.2011, at 19.02, ext Darin Fisher wrote: > > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen > <anssi.kostiai...@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 ]] > It seems like this is information that we have available immediately, and it > is a bit unfortunate that page authors need to delay initialization until > they receive the initial orientation or battery status event. In addition to the above mentioned reason, a synchronous API might encourage web authors to write badly performing code, i.e. poll the battery status via setInterval() too often. In the current event-driven design a new event is dispatched only when the battery status changes. -Anssi _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
