Re: [whatwg] Proposal: Wake Lock API

On Mon, Aug 18, 2014 at 2:04 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
>
>> > 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.

I'd rather have request() and release() work as they are defined now.
Otherwise coordinating becomes even harder as the specification does
not provide a coordination mechanism.

>> 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.

Note that in the API that I'm proposing, there is no way to
accidentally rely on GC behavior. If a WakeLock object is GCed before
it has been release()ed, then the lock is held indefinitely (until the
user leaves the page of course).

I.e. an unbalanced request() and release() in both the currently
proposed API, and in the API that I propose behave the same, the lock
is held indefinitely. Any objects getting GCed does not change this.

Again, I don't feel terribly strongly about this as it's easy to shim
in either direction.

/ Jonas

Received on Monday, 18 August 2014 18:55:50 UTC