W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Proposal: Wake Lock API

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Thu, 17 Jul 2014 20:12:56 +1000
Message-Id: <1405591976.6658.142641405.1A55B5EB@webmail.messagingengine.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: whatwg@lists.whatwg.org
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
> 
> 
> 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. 

Do you have specific UC? The basic UC I have in mind (reading a book,
watching a video, playing a game) would not use a timeout.

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

Why not breaking these in different sub-systems? I can definitely
imagine my phone having the CPU kept at 100% while the screen is off if
it requires to do a heavy computation. Forcing the screen to stay on
while doing that would be a waste of battery.

-- Mounir
Received on Thursday, 17 July 2014 10:13:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC