W3C home > Mailing lists > Public > public-device-apis-log@w3.org > January 2017

[wake-lock] The spec is unnecessarily strict in regard to promise handling

From: Andrey Logvinov via GitHub <sysbot+gh@w3.org>
Date: Tue, 10 Jan 2017 13:07:14 +0000
To: public-device-apis-log@w3.org
Message-ID: <issues.opened-199816517-1484053633-sysbot+gh@w3.org>
andrey-logvinov has just created a new issue for 

== The spec is unnecessarily strict in regard to promise handling ==
The spec actually defines how the user agent must store promises (i.e.
 it has to have a "map" of WakeLock promises per Navigator object and 
always return the same promise for the same wake lock type) but this 
is an implementation detail which doesn't always make sense, as long 
as the returned values remain consistent. I.e. subsequently returned 
promises must be either consistently resolved with the same WakeLock 
object or consistently rejected, but they don't have to be the same 
exact promise object.

Especially in the case where the promise is rejected before it is 
returned from `Navigator.getWakeLock(type)`, e.g. when `type` is 
unsupported, it makes little sense to hold on to the single rejected 
promise for `type`, instead, a new rejected promise can be returned 
each time so that the operation becomes stateless. The latter is much 
easier to implement in Blink than the former.

So I suggest that the spec shouldn't dictate a particular promise 
management mechanism and only specify when the returned promise must 
be rejected or fulfilled, and with which object.

Please view or discuss this issue at 
https://github.com/w3c/wake-lock/issues/92 using your GitHub account
Received on Tuesday, 10 January 2017 13:07:31 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:53 UTC