Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
The batterystatus can be unimportant for pages or apps. Or, detail info is needed more than this. But, before the spec is changed, I think there is no problem to support this. It is better to support to do not. Can you be sure that this will be not used? I think It is good to support to someone try to use this for their apps or pages after spec is published, if it is lacked or not enough now. 2011/6/18 Eric Seidel e...@webkit.org Given how many desktop applications do this, I think we're well off into the land of wishes and fairy tales. :) But it's also possible that libraries like jquery or Google's closure could do this... but again, I'm skeptical. Then again, if we don't expose information like this, they don't ever have a chance to prove me wrong. -eric On Fri, Jun 17, 2011 at 10:54 AM, Darin Fisher da...@chromium.org wrote: I think there are web app developers that would do things differently if they knew their user was running on battery power. An app might scale back its CPU usage, or run a timer at a lower frequency. Crazy idea: Maybe an advertising network could be nice and not show animated ads to such users? ;-) -Darin On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel e...@webkit.org wrote: My 2¢: I'm confused by who the client of this API would be. 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). 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). 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... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: 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
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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. 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. Do we have experience showing that such polling abuse is a problem caused by document.readyState? I think that people would write setInterval based polling code if there were no convenient event subscription API. But, the proposal is to provide both, just as both are provided for page load progress information. Regards, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
We ran into this problem on webOS with orientation where we did not want to have the UI drawn wrong the first time and then (eventually) re-layed out and painted at the correct device orientation. It looked VERY sloppy and web-page-ish, not what we were trying to accomplish. Sure we could have gamed the UA and transmitted the orientation at *just the right time* when the app launched, but that would have been a nasty race condition and yet another quirk. For battery display we used the a proprietary XHR-type with subscription so we could initialize the battery UI+level, and then get updates as the proposed spec is shooting for. 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. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
My 2¢: I'm confused by who the client of this API would be. 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). 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). 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... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
I think there are web app developers that would do things differently if they knew their user was running on battery power. An app might scale back its CPU usage, or run a timer at a lower frequency. Crazy idea: Maybe an advertising network could be nice and not show animated ads to such users? ;-) -Darin On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel e...@webkit.org wrote: My 2¢: I'm confused by who the client of this API would be. 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). 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). 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... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: 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
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Given how many desktop applications do this, I think we're well off into the land of wishes and fairy tales. :) But it's also possible that libraries like jquery or Google's closure could do this... but again, I'm skeptical. Then again, if we don't expose information like this, they don't ever have a chance to prove me wrong. -eric On Fri, Jun 17, 2011 at 10:54 AM, Darin Fisher da...@chromium.org wrote: I think there are web app developers that would do things differently if they knew their user was running on battery power. An app might scale back its CPU usage, or run a timer at a lower frequency. Crazy idea: Maybe an advertising network could be nice and not show animated ads to such users? ;-) -Darin On Fri, Jun 17, 2011 at 10:47 AM, Eric Seidel e...@webkit.org wrote: My 2¢: I'm confused by who the client of this API would be. 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). 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). 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... -eric On Fri, Jun 17, 2011 at 10:40 AM, Darin Fisher da...@chromium.org wrote: 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
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, On 15.6.2011, at 20.25, ext 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. To keep the minimum time as small as possible, the first BatteryStatusEvent should be fed into an appropriate task queue upon event listener registration. An excerpt from the spec: [[ When an event listener is registered with the event type batterystatus, then the User Agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS]. ]] The relevant section in the D3E spec would be: http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. I agree we'll need to handle that case, and that's why the above-mentioned requirement is in the spec. 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. -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen anssi.kostiai...@nokia.com wrote: Hi, On 15.6.2011, at 20.25, ext 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. To keep the minimum time as small as possible, the first BatteryStatusEvent should be fed into an appropriate task queue upon event listener registration. An excerpt from the spec: [[ When an event listener is registered with the event type batterystatus, then the User Agent must retrieve the relevant information and dispatch a BatteryStatusEvent event asynchronously as defined in [DOM-LEVEL-3-EVENTS]. ]] The relevant section in the D3E spec would be: http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#sync-async Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. I agree we'll need to handle that case, and that's why the above-mentioned requirement is in the spec. 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. 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. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi webkit-dev! I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C (http://www.w3.org/TR/battery-status http://www.w3.org/TR/battery-status/ ) This support will be behind the ENABLE_BATTERY_STATUS feature define. There is a meta bug tracking ther feature’s dev(https://bugs.webkit.org/show_bug.cgi?id=62698) After adding this to WebCore, I’m going to add this feature to efl port first. I expect this feature to be eventually enabled by all ports. Should I go ahead and get this added to build.webkit.org's waterfall? Looking forward to your comments. Thank you. Kihong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On 06/15/2011 10:21 AM, 권기홍 wrote: Hi webkit-dev! I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C (http://www.w3.org/TR/battery-status http://www.w3.org/TR/battery-status/) 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[1]. What happens if you have more than one battery? Many modern devices have backup batteries, e.g. to keep the RTC. What is the upgrade path for this event to support applications that want to have a more detailed view (e.g. a dashboard in a server farm that also wants to query the UPS)? sorry for my two cents holger [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/power/power_supply_class.txt;h=9f16c5178b662b8f9ec67f3dd7eafd6f4c89e39a;hb=HEAD ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Dear. holger I agree with you. This spec is too simple, and I think there may be some other needs. So I reported your concern to DAP WG for this spec, I'm joining in the DAP WG in the W3C. But this is a minimum set of battery status report to WebApps or a Web pages, So I think this event and attributes are not dropped. And if this spec is changed or modified, I'll fix or add my source to the WebKit. In my opinion, the WebKit support this feature is no problem now. How do you think about? Thank you for your comment. BR. Kihong Kwon -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Holger Freyther Sent: Wednesday, June 15, 2011 6:41 PM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore On 06/15/2011 10:21 AM, 권기홍 wrote: Hi webkit-dev! I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C (http://www.w3.org/TR/battery-status http://www.w3.org/TR/battery- status/) 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[1]. What happens if you have more than one battery? Many modern devices have backup batteries, e.g. to keep the RTC. What is the upgrade path for this event to support applications that want to have a more detailed view (e.g. a dashboard in a server farm that also wants to query the UPS)? sorry for my two cents holger [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=blob;f=Documentation/power/power_supply_class.txt;h=9f16c5178b66 2b8f9ec67f3dd7eafd6f4c89e39a;hb=HEAD ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
2011/6/15 권기홍 kihong.k...@samsung.com I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C ( http://www.w3.org/TR/battery-status) It seems like the working draft has a couple of TODOs now. Is the spec sufficiently stable? Are other browser vendors implementing this feature? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
From: ryosuke.n...@gmail.com [mailto:ryosuke.n...@gmail.com] On Behalf Of Ryosuke Niwa 2011/6/15 권기홍 kihong.k...@samsung.com I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C (http://www.w3.org/TR/battery-status) It seems like the working draft has a couple of TODOs now. Is the spec sufficiently stable? It's quite stable, just before last call. Here is a editor's draft for LC and there is no TODO in here (http://dev.w3.org/2009/dap/system-info/battery-status.html) Are other browser vendors implementing this feature? I don't think so, but I'm not sure about that. But I'd like to make this to an call for implementation for this spec. Kihong ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, On 15.6.2011, at 17.24, ext Ryosuke Niwa wrote: 2011/6/15 권기홍 kihong.k...@samsung.com I wanted to let you know that I plan to add battery status event support to WebCore. The Battery Status Event is a new feature that is defined by W3C (http://www.w3.org/TR/battery-status) It seems like the working draft has a couple of TODOs now. Is the spec sufficiently stable? Are other browser vendors implementing this feature? As noted by Kihong, the latest draft addresses the TODOs: http://dev.w3.org/2009/dap/system-info/battery-status.html The W3C Device APIs Working Group intends to hit Last Call i.e. stable draft with the above version at the end of this month. On 15.6.2011, at 12.41, ext 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[1]. The topic was, indeed, discussed in the group. We tried a more complex approach, but it did not fly. I can give you some pointers off the list if you're interested in delving into that. What happens if you have more than one battery? Many modern devices have backup batteries, e.g. to keep the RTC. What is the upgrade path for this event to support applications that want to have a more detailed view (e.g. a dashboard in a server farm that also wants to query the UPS)? The spec is intentionally designed to abstract away such details. A typical web app developer should not be concerned about the complexities of multiple batteries a device may have. Further spec specific feedback is welcome, preferably to public-device-apis ML: http://lists.w3.org/Archives/Public/public-device-apis/ -Anssi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
Hi, It seems like the working draft has a couple of TODOs now. Is the spec sufficiently stable? Are other browser vendors implementing this feature? We have interest implementing the battery-status spec for the QtWebKit (and share the common part of the implementation). What happens if you have more than one battery? Many modern devices have backup batteries, e.g. to keep the RTC. What is the upgrade path for this event to support applications that want to have a more detailed view (e.g. a dashboard in a server farm that also wants to query the UPS)? The spec is intentionally designed to abstract away such details. A typical web app developer should not be concerned about the complexities of multiple batteries a device may have. The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Regards, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Brett ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On 06/15/2011 06:58 PM, Brett Wilson wrote: Why would a web page care about whether the battery is being charged when the device is plugged in? Hi, aeh, first of all my mind is playing tricks and I could swear that its battery is being charged was not in the isPlugged description so my comment is void. To answer your question (and leaving aside I am wrong about the isPlugged), in the example[1] one uses isPlugged + charge level to change the polling interval. My point was that just because I have a charger attached, doesn't mean that the device is not emptying the battery (be it I do not have enough current on the USB outlet, a USB hub...). [1] http://dev.w3.org/2009/dap/system-info/battery-status.html#examples PS: If the device is current plugged in is needs probably a ly for the current. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu andr...@google.com wrote: On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. But if the phone is plugged in it can't power down. Most of modern phones don't switch off anymore even if you have the battery low and you play games, surf WiFi, go 3G as soon as you plugged it in. What Brett meant is that it's useless to know that the battery is charging while the phone is plugged in, you just want to know that it will not switch off in any case so you can do whatever you want. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 10:02 AM, Andrei Popescu andr...@google.com wrote: Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. Isn't what you want to use the current battery level? It doesn't really matter whether a battery is charging or not if the current battery level is low because the user might decide to unplug the device as soon as you started downloading something, in which case, the device can power off if the batter level is low. On Wed, Jun 15, 2011 at 10:08 AM, Holger Freyther ze...@selfish.org wrote: To answer your question (and leaving aside I am wrong about the isPlugged), in the example[1] one uses isPlugged + charge level to change the polling interval. My point was that just because I have a charger attached, doesn't mean that the device is not emptying the battery (be it I do not have enough current on the USB outlet, a USB hub...). I'd argue that isPlugged should be false in such a case. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 6:08 PM, Alexis Menard alexis.men...@openbossa.org wrote: On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu andr...@google.com wrote: On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. But if the phone is plugged in it can't power down. Most of modern phones don't switch off anymore even if you have the battery low and you play games, surf WiFi, go 3G as soon as you plugged it in. What Brett meant is that it's useless to know that the battery is charging while the phone is plugged in, you just want to know that it will not switch off in any case so you can do whatever you want. Ugh, you're right, I just misunderstood Brett's question :) In fact, as Holger points out, isPlugged actually implies that the battery is being charged. Andrei webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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. Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. On Wed, Jun 15, 2011 at 10:08 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu andr...@google.com wrote: On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. But if the phone is plugged in it can't power down. Most of modern phones don't switch off anymore even if you have the battery low and you play games, surf WiFi, go 3G as soon as you plugged it in. What Brett meant is that it's useless to know that the battery is charging while the phone is plugged in, you just want to know that it will not switch off in any case so you can do whatever you want. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
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. -Darin On Wed, Jun 15, 2011 at 10:25 AM, Greg Simon gregsi...@chromium.org 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. Otherwise the web application starts at full-throttle (burning battery) on a device with 10% battery left until it *drains* enough to get a batteryEvent. On Wed, Jun 15, 2011 at 10:08 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu andr...@google.com wrote: On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote: On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote: Hi, The use-case for us is to enable content developers to implement rudimentary power management (e.g. to stop expensive operations on the page, perhaps save state). I'm not sure if this API is really meant for accurately reporting all the possible power management states of the system as Anssi pointed out. Okay, point on complexity taken. My question is what if you want to add complexity, is there something in the event that prevents that (I have no idea about DOM compatibility issues)? Don't get me wrong I think having more device support is great. My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee that the battery is getting charged. Is this a problem? Why would a web page care about whether the battery is being charged when the device is plugged in? Because it would know not to start doing things that drain the battery. For instance, powering up a 3G antenna to download your latest emails could be annoying to users if the battery level is too low. 3G takes quite a bit of power and the device would be in danger of powering down. But if the phone is plugged in it can't power down. Most of modern phones don't switch off anymore even if you have the battery low and you play games, surf WiFi, go 3G as soon as you plugged it in. What Brett meant is that it's useless to know that the battery is charging while the phone is plugged in, you just want to know that it will not switch off in any case so you can do whatever you want. Thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore
On Wed, Jun 15, 2011 at 11:29 AM, Darin Fisher da...@chromium.org 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. I agree. I'm rather surprised by the fact the current draft doesn't provide any API for that. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
