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

Re: DAP-ISSUE-166: Should getBattery() always return the same promise?

From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
Date: Fri, 8 Aug 2014 09:47:22 +0000
To: Device APIs Working Group <public-device-apis@w3.org>
Message-ID: <0E15F05B-343E-4681-98A4-6EA3B68B5A93@intel.com>
Hi All,

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

> DAP-ISSUE-166: Should getBattery() always return the same promise?
> 
> http://www.w3.org/2009/dap/track/issues/166
> 
> Raised by: Mounir Lamouri
> On product: 
> 
> http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0003.html
> 
> [[
> 
> Hi,
> 
> When I wrote the getBattery() prose, I made it so that getBattery()
> would return a new promise every time it is called but it would always
> return the same BatteryManager when the promise is resolved.
> 
> I realised that this requirement probably doesn't make much sense and we
> might want to spec getBattery() as returning always the same promise. In
> other words, navigator.getBattery() === navigator.getBattery(). The
> intent isn't really to get the equality but that way, we simplify the
> implementation because implementing this only require to keep track of
> that one promise.
> 
> WDYT?
> 
> ]]

I see no downsides in doing this, thus I suggest we change to the following:

[[

* Let /promise/ be a newly created Promise and return it.

]]

Into:

[[

* If there is an initialized-but-unresolved Promise object returned by getBattery(), let /promise/ be that Promise object.
* Otherwise, let /promise/ be a newly created Promise.
* Return /promise/.

]]

For the contest, please see:

https://dvcs.w3.org/hg/dap/raw-file/default/battery/Overview.html#the-navigator-interface

All - please report any bugs in the algorithm, and let us know if you have any concerns with this change. Iíll land this change later if I hear no concerns.

Thanks,

-Anssi
Received on Friday, 8 August 2014 09:47:51 UTC

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