On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher <[email protected]> wrote: > > > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen > <[email protected]> wrote: >> >> Hi, >> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote: >> > >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen >> > <[email protected]> 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. Thanks, Andrei _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
