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

On Mon, Aug 18, 2014 at 5:10 PM, Domenic Denicola
<domenic@domenicdenicola.com> 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.
>
> 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

Nope, doesn't work.  You can't build anything more complex on top of a
simple request/release (or a boolean, which is equivalent), because
any other library can come along and screw with the lock.  So, if we
want this to be extensible, we still need to design it in a localized
way so that you can have multiple independent locks.

If we did that, we *could* then layer a visibility/promise-based thing
on top as an auto-release mechanism for a specific lock.  But you've
still got to solve at least one problem correctly.

~TJ

Received on Tuesday, 19 August 2014 00:23:57 UTC