Wake Lock API as [Observable] candidate, Re: [whatwg] Object.observe()able properties on the web platform

On August 25, 2014 at 2:14:09 PM, Boris Zbarsky (bzbarsky@mit.edu) wrote:
> On 8/25/14, 1:17 PM, Rafael Weinstein wrote:
> > I'm supportive of this idea. I'd suggest starting with input.value
>  
> This one is actually extra-fun from a performance standpoint.

As device APIs seem to be well-suited to using an observable pattern (I'm thinking of things like the Battery API - though I'm not suggesting we change that API), I'm wondering if we can maybe discuss the Wake Lock API that a few of us are interested in standardizing? 

At a very basic level, the problem space is as follows:

1. The Wake Lock API depends on IPC: both in requesting the lock and getting notified by the underlying OS that it cannot honour a lock (wake lock is released when battery is critical, for example). Hence, setting a wake lock is an async operation, but to script it can appear sync.   

2. The API should probably be restricted to the top-level browsing context (don't want random advertisements in an iframe keeping the screen on, for example). As far as observing is concerned, I would guess this one doesn't matter - just trying to point out that setting behaviour is contextual.

3. Should such an API be an extension to Document or similar DOM interfaces? or should it be its own interface? I guess my question is: do you foresee performance implications to adding these kinds of APIs to things that are somewhat dynamic and already contain a bunch of (currently non-observable) attributes, like the Document object has. I imagine this makes no difference, but thought I'd ask just in case.


```
document.keepScreenOn = true; 
```

Versus, say: 

```
window.WakeLock.keepScreenOn = true; 
```

Your guidance would be much appreciated.

Received on Monday, 25 August 2014 18:55:34 UTC