Re: [whatwg] Proposal: Wake Lock API

On Sat, 16 Aug 2014, at 08:40, Jonas Sicking wrote:
> 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

There might have been some discussions in the DAP WG (but the archives
website isn't helping). There was definitely at thread in blink-dev [1]
and you might want to have a look at the GitHub repo [2]. By the way, it
seems that this API might be worked in the DAP WG [3].

> > 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.
> 
> If there's only one subsystem of the page that uses a display lock,
> then this is not a big deal. The extra call to release() would cause
> an rejection, but hopefully that won't break the page.

It is possible that the API might behave differently and the first
release() will release the lock even if lock() was called multiple
times. I guess the scope of the lock could be the browsing context so a
website will not end up conflicting with iframes. However, if a websites
embeds libraries that use this API, it will need to coordinate.

> However if there are multiple subsystems that all use a display lock,
> it would mean that those subsystems might stomp on each other's
> attempts at holding a display lock. The effect would be that the
> display lock is released too early.
> 
> I don't care strongly about this though. It's pretty easy for pages to
> write a wrapper around the currently proposed API to implement the API
> that I'm proposing.

I understand the problem and I agree that an object-based approach would
be nicer in theory because the scope of the lock would be well defined.
However, it's a very uncommon pattern as far as Web APIs are concerned
and I would worry that developers would end up  doing things wrong and
depend on the GC behaviour without even being aware of it.

[1]
https://groups.google.com/a/chromium.org/d/msg/blink-dev/SzVuAi2KRhA/OaNDiHOKl8gJ
[2] https://github.com/w3c/wake-lock
[3]
http://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0035.html

-- Mounir

Received on Monday, 18 August 2014 09:05:19 UTC