W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

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

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Tue, 26 Aug 2014 10:47:55 -0400
Cc: Frederick Hirsch <w3c@fjhirsch.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-script-coord@w3.org
Message-Id: <B78E2779-0624-47CE-9BCC-3E4755AE259E@fjhirsch.com>
To: Marcos Caceres <w3c@marcosc.com>
Is now a good time to  take the WakeLock thread to the DAP public list? ( public-device-apis@w3.org ) 

regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch



On Aug 25, 2014, at 2:55 PM, Marcos Caceres <w3c@marcosc.com> wrote:

> 
> 
> 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 Tuesday, 26 August 2014 14:49:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC