Re: DAP-ISSUE-167: Should Promises be used in Battery API [Battery Status API]

Hi All,

On 04 Aug 2014, at 22:32, Device APIs Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

> DAP-ISSUE-167: Should Promises be used in Battery API [Battery Status API]
> 
> http://www.w3.org/2009/dap/track/issues/167

[For all the related discussion, please see the above issue.]

In order to help us move forward with this, here’s my (likely incomplete) recollection of the pros and cons of the promise-based API [1] discussed on this list so far:

Pros:

* Better fit for the multi-process architecture (Chrome, Cordova mentioned)
* Efficiency of the implementation (off the critical path, can be enabled on demand, does not block on the 1st get); Rick’s measurements at [2]
* Can be gated behind a permission mechanism (current implementations do not, spec does not require this, but mentioned that some future implementations might want to do this)

Cons:

* Backwards incompatible change (Firefox [OS], Tizen mentioned shipping the sync API [3])
* API ergonomics arguably worse (can this be mitigated with a JS library such as battery.js?)

Does this list resonate with others? Please help me complete or fix it.

Also, it’d be helpful to get confirmation on Mozilla’s position. In April we heard (via Google’s participant) Mozilla "has indicated that they would be fine with such change” [4], but no names were mentioned.

I’d love us to reach consensus on this soon, as web developers will ultimately be the ones to suffer if we end up shipping two incompatible implementations — that’d be a sad panda moment for all of us. I’m optimistic we can resolve this, given this is, after all, a rather simple API.

Thanks,

-Anssi

[1] https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0046.html
[3] http://www.w3.org/TR/battery-status/
[4] http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0037.html

Received on Friday, 8 August 2014 10:54:26 UTC