On Wednesday, July 16, 2014 at 5:59 AM, Mounir Lamouri wrote:
> On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote:
>
> I do not think we should have this timeout option. That sounds like a
> very week use case and something fairly easy to do with the tools the
> platform already provides. The argument to support this feature in the
> github issue was that it will prevent developers to forget releasing the
> lock but I have a hard time believing that developers forgetting to
> release a lock would use a timeout that is probably more painful and
> error-prone.
I don't have a strong opinion. My concern was mostly about developers having to
watch for a whole bunch of different interaction queues (touch events, mouse
events, focus events, orientation-change events, etc.) in order to release the
lock at the right time.
I'm happy to see how people make due without it, and if we find too many
problems we can always add this later.
> > ### Check if lock is already set
> > It might be useful to also have a way of checking if a lock is already
> > set:
> >
> > ``
> > readonly attribute WakeLockType? lockType
> > ```
>
>
>
> You might want something like:
> partial interface WakeLock {
> readonly attribute WakeLockType[] currentLocks;
> };
>
> Given that there can be multiple locks applying at the same time.
>
> Otherwise, the proposal sounds good to me.
Could be... I was thinking that the locks are kinda like a fallback chain. That
is, if you have the "screen" you also have "system". If you lose "screen"
(notified via an event), you request "system" before the device goes to sleep.
If it's not possible to do things in that order, then yes: we would need to
return a list of the current locks.
Question remains if there are other kinds of locks that we might need. For
example, Firefox OS has "wifi" as a lock type. I'm assuming that their model
keeps the "cpu" on, but the device can still shut down the radios on a device.
In the proposal, we lump "wifi" and "cpu" into "system".
