[webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Ki-hong Kwon]

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 <eric at 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 <darin at 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 <eric at 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 <darin at chromium.org>
> wrote:
> >> >
> >> >
> >> > On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu <andreip at google.com>
> >> > wrote:
> >> >>
> >> >> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher <darin at chromium.org>
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >> >> > <anssi.kostiainen at 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.kostiainen at 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 at lists.webkit.org
> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >> >
> >> >
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110618/7a6fafed/attachment-0001.html>