Re: [whatwg] Proposal: Wake Lock API

On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
<nils@dieweltistgarnichtso.net> wrote:
> Jonas Sicking <jonas@sicking.cc> writes:
>> On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
>>> On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
>>>> I am however more worried about that only having a request() and a
>>>> release() function means that pages that contain multiple independent
>>>> subsystems will have to make sure that they don't stomp on each
>>>> other's locks. Simply counting request() calls vs. release() calls
>>>> helps, but doesn't fully solve the problem. It's very easy to
>>>> accidentally call release too many times, in response to some UI
>>>> action for example.
>>>>
>>>> An alternative design would be something like
>>>>
>>>> x = new WakeLock("display");
>>>> x.request();
>>>> x.release();
>>>>
>>>> Extra calls of either request() or release() are ignored, but pages
>>>> can create any number of WakeLocks of the same type.
>>>
>>> It seems that we already discussed using an object and this solution was
>>> dismissed because of this model being error-prone.
>>
>> Where was this discussed? Why was it considered more error prone? Was
>> it related to the patterns discussed at
>>
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html
>>
>>> It's also not clear
>>> how this solution is superior than the current solution [1] with regards
>>> to multiple releases or requests. In [1], if you call .request() or
>>> .release() multiple time, the promise reacts appropriately.
>>
>> The problem arises when you have several semi-independent pieces of
>> code within a single page. Given that request() and release() is
>> likely going to happen in response to very different UI events or IO
>> events, it makes it fairly easy to accidentally have unbalanced calls.
>>
>> Consider for example a lock which is released either when a video
>> reaches its end, when the user presses the pause button, or when the
>> user close the <dialog> in which the video is rendered. It seems quite
>> easy to end up with a race where if the user close the <dialog> right
>> when the video ends, that release() would get called twice. Or if the
>> user pause the video first and then close the <dialog> that release()
>> would get called twice.
>
> Seems to me a declarative solution (like CSS) might be appropriate.
>
> @media screen {
>     video:playing {
>         wake-lock: display 15s;
>     }
> }
>
> article.recipe:target {
>     wake-lock: display;
> }

That's not a terrible idea.  The CSSWG is generally hesitant to put
behavior-altering things in CSS, but some bleed-through is fine, and
this can be argued as an aspect of appearance.

This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).

~TJ

Received on Monday, 18 August 2014 15:02:16 UTC