- From: Frederick Hirsch <w3c@fjhirsch.com>
- Date: Fri, 23 May 2014 12:24:37 -0400
- To: W3C Device APIs WG <public-device-apis@w3.org>
- Cc: Frederick Hirsch <w3c@fjhirsch.com>, timvolodine@google.com, Mounir Lamouri <mounir@lamouri.fr>
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