W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2014

Re: Battery Status API asynchronous amendment

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Fri, 2 May 2014 08:35:04 +0000
To: Tim Volodine <timvolodine@google.com>, "<public-device-apis@w3.org>" <public-device-apis@w3.org>
Message-ID: <6A983BF6-04E3-45B8-9107-BB059B17B474@intel.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:07 UTC