Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Holger Freyther]

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 )

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

[Kihong Kwon]

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

[Ryosuke Niwa]

2011/6/15 권기홍 
>
> 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

[Kihong Kwon]

> From: ryosuke.n...@gmail.com [mailto:ryosuke.n...@gmail.com] On Behalf Of 
> Ryosuke Niwa

> 2011/6/15 권기홍 
> 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

[Anssi Kostiainen]

Hi,

On 15.6.2011, at 17.24, ext Ryosuke Niwa wrote:

> 2011/6/15 권기홍 
> 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

[laszlo.1.gombos]

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

[Holger Freyther]

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

[Brett Wilson]

On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  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

[Andrei Popescu]

On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson  wrote:
> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  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

[Holger Freyther]

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

[Alexis Menard]

On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu  wrote:
> On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson  wrote:
>> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  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

[Ryosuke Niwa]

On Wed, Jun 15, 2011 at 10:02 AM, Andrei Popescu  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  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

[Andrei Popescu]

On Wed, Jun 15, 2011 at 6:08 PM, Alexis Menard
 wrote:
> On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu  wrote:
>> On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson  wrote:
>>> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther  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

[Greg Simon]

>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  wrote:

> On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu 
> wrote:
> > On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson 
> wrote:
> >> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther 
> 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

[Darin Fisher]

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  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 
>> wrote:
>> > On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson 
>> wrote:
>> >> On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther 
>> 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

[Ryosuke Niwa]

On Wed, Jun 15, 2011 at 11:29 AM, 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.


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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Anssi Kostiainen]

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

[Darin Fisher]

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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Anssi Kostiainen]

Hi,

On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> 
> On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen 
>  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

[Darin Fisher]

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

[Andrei Popescu]

On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher  wrote:
>
>
> On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
>  wrote:
>>
>> Hi,
>>
>> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
>> >
>> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
>> >  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

[Darin Fisher]

On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu  wrote:

> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher  wrote:
> >
> >
> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >  wrote:
> >>
> >> Hi,
> >>
> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >
> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> >  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

[Greg Simon]

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  wrote:

> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher  wrote:
> >
> >
> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >  wrote:
> >>
> >> Hi,
> >>
> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >
> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> >  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

[Eric Seidel]

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  wrote:
>
>
> On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu  wrote:
>>
>> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher  wrote:
>> >
>> >
>> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
>> >> >
>> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
>> >> >  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

[Darin Fisher]

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  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  wrote:
> >
> >
> > On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu 
> wrote:
> >>
> >> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher 
> wrote:
> >> >
> >> >
> >> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >> >  wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >> >
> >> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> >> >  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

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Eric Seidel]

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  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  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  wrote:
>> >
>> >
>> > On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu 
>> > wrote:
>> >>
>> >> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher 
>> >> wrote:
>> >> >
>> >> >
>> >> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
>> >> >  wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
>> >> >> >
>> >> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
>> >> >> >  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 underl

Re: [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 

> 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  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  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 
> wrote:
> >> >
> >> >
> >> > On Fri, Jun 17, 2011 at 10:27 AM, Andrei Popescu 
> >> > wrote:
> >> >>
> >> >> On Fri, Jun 17, 2011 at 4:21 PM, Darin Fisher 
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Jun 17, 2011 at 4:11 AM, Anssi Kostiainen
> >> >> >  wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> On 16.6.2011, at 19.02, ext Darin Fisher wrote:
> >> >> >> >
> >> >> >> > On Thu, Jun 16, 2011 at 5:12 AM, Anssi Kostiainen
> >> >> >> >  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.
> >>

Re: [webkit-dev] Adding ENABLE_BATTERY_STATUS to WebCore

[Robin Berjon]

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