Re: Battery Status API asynchronous amendment

Hi Tim, All,

On 30 Apr 2014, at 15:30, Tim Volodine <timvolodine@google.com> wrote:

> We are proposing a change to the current Battery Status API (http://www.w3.org/TR/battery-status/) such that it is completely asynchronous. This will allow for less constrained and more efficient current and future implementations.
> 
> More concretely the proposal is to return the battery object asynchronously as a promise, e.g.
> 
> function onBatterySuccess(battery) {
>   console.log(batery.level);
> }
> function onBatteryFailure(msg) {
>   console.log("battery information not available");
> }
> navigator.getBattery().then(onBatterySuccess, onBatteryFailure);
> 
> Mozilla who has the only browser currently shipping the Battery Status API has indicated that they would be fine with such change. We are currently in the process of implementing this API in chrome as well.

Thanks for your proposal. Could you work with Mounir to come up with a patch to the spec that the group could review? I’m also happy to help, but I think it would be better for you to do it, given you're in the process of implementing right now. Please use the Editor’s Draft as a starting point [1].

While I applaud modern API design practices in general, there’s one thing I want the group to understand:

As we know, one of the core principles of web technologies is backwards compatibility, thus we need to be careful and consider how the existing implementations are able handle the transition so that compatibility with existing content is maintained (presupposing we do not have control over all the content using the API, and there’s a meaningful amount of such content).

I’d guess a viable strategy for existing implementations might be to ship both the sync and async API in parallel for some time, start logging warnings to the console for the sync API usage, and in some future release when the usage of the sync API is below a certain threshold deprecate the sync API.

That said, this would still pose some near-term challenges for the interop and testing, given optionality that must be introduced in the specification.

Perhaps someone from Mozilla could clarify how the transition in Firefox is planned to be handled, so that we can give some reasonable guidance for implementers in the spec?

Thanks,

-Anssi

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/battery/Overview.html

Received on Friday, 2 May 2014 08:35:41 UTC