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