[battery] CfC agreed to update Battery with async/promises proposal

The CfC to update the Battery API  [1] with the async proposal http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0037.html  has been approved, with  explicit support on the list [2][3] (and no objections).

Tim has drafted a set of detailed changes for the specification (thanks) ; please review: http://lists.w3.org/Archives/Public/public-device-apis/2014May/0043.html

Anssi noted in his support that we need to manage a smooth transition, as mentioned in his earlier comments [4]. do implementers have any comment? 

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch

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

[2] http://lists.w3.org/Archives/Public/public-device-apis/2014May/0039.html

[3] http://lists.w3.org/Archives/Public/public-device-apis/2014May/0041.html

[4] http://lists.w3.org/Archives/Public/public-device-apis/2014May/0005.html

On May 15, 2014, at 2:30 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:

> This is a Call for Consensus to  change update the Battery specification with the async proposal as outlined in http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0037.html 
> 
> Quoting that proposal:
> 
> [[
> 
> 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);
> 
> ]]
> 
> In addition, this CfC includes the decision that this API returns aggregated energy - if information were needed about multiple batteries individually that would require another API (see http://lists.w3.org/Archives/Public/public-device-apis/2014May/0001.html )
> 
> Approval of this CfC will subsequently require a detailed set of changes to the text of the specification, a return to Last Call and then CR and revised implementation/interop test support for progressing the revised specification. Implementers indicating support for the CfC would be most valuable.
> 
> Please respond to this CfC on the public list indicating support or any concern with the change (even a +1 in support is helpful). No response will be taken as signifying  agreement. 
> 
> Please respond by next Thursday, 22 May 2014.
> 
> Thanks
> 
> regards, Frederick
> 
> Frederick Hirsch, Nokia
> Chair XML Security WG
> 
> For tracker, this will complete ACTION-691
> 
> 
>

Received on Friday, 23 May 2014 16:25:10 UTC