Re: Feedback about Battery Status Events

Hi,

On 17.10.2011, at 23.40, ext Mounir Lamouri wrote:

> I would prefer to require UA to make sure all battery attributes are set when window.navigator.battery is returned. It is doable and would make things way much easier for authors.

Perhaps we should default 'level' to 100 and 'charging' to true as Jonas suggests?

>> I like your proposal's clearly named *change events (should they be prefixed with battery, e.g. statuschange is a rather generic name for an event?).
> 
> The events are fired on the BatteryManager object. It doesn't seem useful to prefix those events with "battery" then.

If the *change events do not bubble then more terse names are better. But if we want to have them bubble then wouldn't this be valid, but a bit ambiguous:

window.addEventListener('levelchange', function () {}, false);

Are there any use cases for bubbling? If bubbling is not needed then your proposal sounds good to me.

>> Returning null was discussed starting at [4]. Hot plugging was the main argument against returning null, it was also argued that some information about the battery should be always returned even if there's no battery (Robin may want to elaborate on that one?).
> 
> If we do not return null when there is no battery (which I think makes sense), we should probably say that the battery is fully charged, and charging when the status is requested.
> One downside here is we wouldn't be able to know if the device is currently using a battery or is only plugged. That information wouldn't be useful for most websites but that would be an issue if we want to build an API useful in a web as a platform point of view. Maybe we could add a "nbBatteries" attribute but in that case, we might increase fingerprinting issues.

What do you mean by 'nbBatteries'?

Based on what you and Jonas say, it sounds like it makes sense to set 'level' to 100 and 'charging' to true if there's no battery, similarly to uninitialized state discussed above.

>>> Finally, the Battery Status Events specification introduces a 'status' attribute that can be 'ok', 'low' or 'critical' our implementation keeps that but we might be tempted to remove it. Indeed, from where the thresholds should come from? The Battery Status Events specifications say it should be left to the implementation but how can the implementation set sensitive values? Do battery internally have a 'low' indicator? In addition, even if the UA set the thresholds, they might not fit what applications are expecting. In that case, we should probably allow those applications to set them. However, that would be very similar than just listening to level changes and put the very simple logic in the event handler.
>> 
>> The rationale for statuses was that not all batteries are equal and that the underlying platforms typically know better when the battery's level is low or critical, depending on the decay rate and other parameters. Mapping statuses to certain level thresholds may not be an optimal approach, but is a viable implementation strategy if the platform does not expose more than that. This issue was discussed at [1] and [5].
> 
> If I understand it correctly, 'low' and 'critical' have been added to be able to listen to some events that would let the application know when the battery is low/critical based on the current power consumption but what the specifications actually require is to have a level threshold for that? I'm not sure if it matches the use case.

It should be clarified in the spec that the thresholds may vary over time depending on characteristics of the system (load, battery cycles etc.). You can check my JavaScript implementation of the spec to get a feel of the behavior (in this JS implementation the thresholds are naturally hardcoded):

  http://dev.w3.org/2009/dap/docs/battery-status/battery-status.html

> Knowing if the battery is low based on the power consumption is reflected in the remaining time. We should probably add a 'remaining' attribute to BatteryManager that would return the remaining time until the battery is charged/discharged.

We looked into this, and it appeared time remaining is not supported on all relevant platforms:

  http://lists.w3.org/Archives/Public/public-device-apis/2011May/0043.html

It looks like most of the open issues would be addressed if the remaining time would be there (or if the level would be bound to the remaining time, i.e. level = 100 (cur_battery_time / max_battery_time)).

I'm wondering if we could have it in the spec even if not all the relevant platforms support it. How about we make it optional and make sure the API is still useful if it's not present? We did discuss this and agreed to drop it but perhaps we need to reconsider that.

> With this information, do we still need a low/critical status? It seems that the APIs that provide low/critical notifications are always based on remaining power (.level) and/or remaining time (.remaining). If UAs are requested to provide those events based on platform conventions, it might be hard because some platforms only have a 'low' event and some might have three events instead of two. UAs will probably have to do some arbitrary choices and based on that, authors might want to override them but with the threshold being based on .level or .remaining, having an API to customize them might be painful.
> Given that Battery API would be providing all needed information to implement those notifications in a script, I wonder if we could just assume that authors will handle that themselves and use libraries if needed?

If .remaining would be exposed, then it would pretty much render low and critical statuses useless, because I think that for most use cases it is more helpful to know how much time is left than to know that the battery is critically low. That said, given that not all platforms currently provide remaining time estimates (and even if they do, they may not be too reliable), having abstract low and critical statuses seemed like a good compromise.

> Ideas and feedback would be more than welcome here :)

Keeping low and critical statuses is a compromise for the lack of time remaining. If we add time remaining those could be dropped.

>> It is possible that the battery depletes even if it is plugged in under heavy load if the charging currency is low enough. Should the design support such a corner case? If not, your proposal is simpler, and simpler is typically better, but we should make sure it is unambiguous.
> 
> I don't think we care that much about that edge case. Anyhow, using a "charging" or "state" attribute would handle it better given that "plugged" only say if the device is plugged. While the two others would tell if it is charging or not. Implementors could return "discharging" if the device is plugged to a source that gives less power that it is currently using.

Jonas suggested the corner case is covered by having 'level' around, so I think I can align with your 'charging' proposal.

> Thank you for your feedback.

Same to you!

I'll start baking these changes in to the W3C spec in the coming days, if I don't hear any arguments against.

-Anssi

Received on Tuesday, 18 October 2011 14:09:35 UTC