Re: [whatwg] Preventing wake lock leaks with DOM nodes

(sorry, accidental send before!)


On Monday, August 18, 2014 at 8:10 PM, Domenic Denicola wrote:

> In general I feel this thread has taken a turn for the complex. Why don't we just do what other platforms do, and provide a simple global request/release mechanism (or toggleable Boolean property!), which developers can build on top of? A lot of the ideas here seem to be trying to create the perfect, developer-friendly, foolproof API. Some of them seem quite clever too, tying to page visibility and the like. But all of them could be built, as libraries, on top of a global request/release. That way users could get reference counting if they want that, visibility-based locking if they want that, promise-based locking if they want that, timeouts if they want those, or even just not do any of those if their use case is simple enough that it doesn't warrant anything more complicated than what they are already doing on existing platforms.

The reason I didn't make it a boolean was because of the IPC involved and because I wanted to support multiple types of locks without needing to add new attributes in the future (and if we need to add the complex stuff later). The request()/release() mechanism is well suited for that, IMO. And it's also fairly simple, even if it vends a promise.

Admittedly, I could just make it a bunch of boolean attributes. The spec is kinda already designed to work that way (what lock is applied is just a flag, which is checked synchronously)... it's how `isHeld(lockType)` works.

About tying it to visibility, and time, etc. Those are nice to have, but can certainly do without for now. We already dropped the timeout stuff from the original spec - but certainly a nice to have in the future. Having said that, if we know that this API is going to be used in conjunction with scroll events, then we know we are going to have potential battery eating problems (beyond just keeping the screen on). 
> 
> We don't need to solve Hard Problems in Programming (TM) before we expose a wake lock API. Leave that as a subsequent step, which users can do, while we move on to exposing more missing platform capabilities
> 

Yeah, certainly want to keep it as simple as possible. Just want to cover keeping the screen on for now.

Received on Tuesday, 19 August 2014 00:36:05 UTC