- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Wed, 16 Jul 2014 19:59:44 +1000
- To: Marcos Caceres <w3c@marcosc.com>, whatwg@lists.whatwg.org
On Wed, 16 Jul 2014, at 05:21, Marcos Caceres wrote: > ### Timeouts > We are thinking of adding a dictionary to hint at the system the amount > of time it should hold the lock for (in ms). So, then the developer can > express holding the lock for 5 minutes (e.g., ebook case, instead of > having to bind a whole bunch of listeners and constantly having to > request the wake lock). This would allow the UA to add whatever time the > developer requested to its normal wake lock timer + additional time the > developer might want. If the timeout is less than the default timeout, it > can just be ignored. > > ``` > dictionary WakeLockOptions{ > unsigned long timeout; > } > ``` > > For example: > ``` > //I only need this for ~5 mins here. > var options = {timeout: 1000 * 60 * 5}; > navigator.wakeLock.request("display", options); > ``` 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. > ### 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. -- Mounir
Received on Wednesday, 16 July 2014 10:00:17 UTC