[wake-lock] Plans for v2

andrey-logvinov has just created a new issue for 
https://github.com/w3c/wake-lock:

== Plans for v2 ==
So far, the main identified problems are:
1. Not friendly to components: a single flag for the entire browsing 
context.
2. Only on kind of wake lock is supported without a possibility of 
easy extension.
3. No actual wake lock state feedback to the script.

So I propose the following informally described API:
`Navigator.createWakeLock(type)` returns a `Promise<WakeLock>`, a new 
one each time, which is resolved if the browser supports this type of 
wake lock and this type of wake lock is not disabled by a user 
setting, or the user granted permission to use this type of wake lock.
 Otherwise, the promise is rejected. 

The WakeLock object is an interface through which the wake lock can be
 managed and has the following layout:
```
interface WakeLock {
    readonly attribute string type; // Wake lock type (constant)
    attribute boolean applied; // True when the wake lock of this type
 is currently applied by the browser
    attribute EventHandler onstatuschange; // Event to listen to 
determine if this type of lock 
                                           // is currently applied
    Promise<WakeLock> apply(); // This requests wake lock application.
 This time, the promise 
                               // is resolved when the wake lock is 
actually applied, so a script has an opportunity 
                               // to wait (asynchronously) until the 
lock is applied. The promise is resolved 
                               // with the same wake lock object (to 
simplify chaining) and is never rejected.
    void cancel();  // Cancels wake lock request through this WakeLock
 object
}
```
The wake lock requests are multiplexed for all WakeLock objects 
created in this context; i.e. if there is an outstanding wake lock of 
the given type, the wake lock request for this context is requested, 
otherwise cancelled.
The wake locks usually have a hierarchy (screen wake lock implies 
system wake lock), but the proposed API organization does not rely on 
it.

The component friendliness problem is solved by the fact that multiply
 WakeLock objects can be created independently in the same context. 
Specifying the wake lock type enables a script to request a specific 
type of wake lock, and support for new types can be added without 
changing the API. The feedback problem is solved by allowing the 
script to optionally wait for wake lock application and to further 
monitor the wake lock state through WakeLock.onstatuschange event.

Please view or discuss this issue at 
https://github.com/w3c/wake-lock/issues/87 using your GitHub account

Received on Tuesday, 29 November 2016 16:23:11 UTC