Re: Feedback about Battery Status Events

On 10/05/2011 02:04 PM, Anssi Kostiainen wrote:
> Hi,
>
> On 4.10.2011, at 17.55, ext Mounir Lamouri wrote:
>
>> As part of the WebAPI effort at Mozilla [1], we did write a draft implementation of something we are calling Battery API [2] (inspired by the Battery Status Events). Those two specifications are close and we would like to give some feedback on the changes we did and the changes we might want to discuss.
>>
>> The major change we did is actually making the API synchronous: the BatteryManager object has a few attributes that give the current state of the device's battery. The DAP specification requires to use an event handler to get those information but we believe there are use cases where a developer might just want to get some information at a given moment without caring about changes and this shouldn't be harder than reading an attribute. For example, a game might disable some features if the battery is low but these features will not magically appear during the game if the device is plugged, it might change between two levels instead.
>
> The Battery Status Events was inspired by DeviceOrientation, so most of the asynchronous model was inherited from it. I agree that there are high value use cases for a synchronous API. The only concern I have with the synchronous API is potential for race conditions due to battery-related subsystems being slow to initialize, or blocking. However, your proposal seems to be fairly similar to document.readyState (and document.onreadystatechange) in its design so I believe we could handle the above concern similarly by defining default values to all the attributes. For example, the attributes could be nullable, and null could indicate uninitialized state (cf. readyState defaults to 'loading'):
>
> var b = window.navigator.mozBattery;
> console.log(b.level); // null if uninitialized
>
> b.addEventListener('levelchange'), function () {
>     console.log(b.level); // always non-null
> });

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.

> 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.

> 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.

>> 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.
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.
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?

Ideas and feedback would be more than welcome here :)

> 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.

Thank you for your feedback.
--
Mounir

Received on Monday, 17 October 2011 20:40:39 UTC