On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu <andr...@google.com> wrote:
> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher <da...@chromium.org> wrote: > > > > > > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen > > <anssi.kostiai...@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.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 > >> > >> ]] > > > > 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev