Re: Standby API Specification Proposal

> requestWakeLock makes it easy to forget to remove the lock; poke() makes
> it harder (the wake lock disappears as soon as you stop poking).
> 
> Another aspect where managing lock will trip people up: if several
> distinct libraries try to manage it, they have to carefully manage the
> state to avoid unlocking someone else's lock.

This was my concern in my first point, programmer usability & avoiding errors  (I mentioned security as an aside, which obscured my main point I guess)

Simplicity of use, avoiding errors. With multiple threads could locks become an issue?

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch

On May 28, 2014, at 9:17 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:

> Le mercredi 28 mai 2014 à 08:54 -0400, Marcos a écrit :
>>> I suggest that we should attempt to avoid the risk of apps requesting  
>>> locks and then not freeing them due to programmer error or other  
>>> error conditions. (One denial of service attack might be to disable  
>>> screen sleep to either cause burn-in or battery drain..)
>> 
>> I seriously don't see this as a real problem, as if one closes the app
>> or opens a different tab the lock no longer applies (i.e., this only
>> applies to foregrounded windows). 
> 
> Agreed; more specifically, I think both proposals on the table have the
> same properties with regard to security.
> 
>>> it seems Dom’s poke proposal gets at the idea of allowing programmatic  
>>> notice of input other than touch, avoiding the issue of locks  
>> 
>> Not sure I follow how it avoids the issue of locks? Not sure what
>> "locks" means in this context?   
> 
> requestWakeLock makes it easy to forget to remove the lock; poke() makes
> it harder (the wake lock disappears as soon as you stop poking).
> 
> Another aspect where managing lock will trip people up: if several
> distinct libraries try to manage it, they have to carefully manage the
> state to avoid unlocking someone else's lock.
> 
>> I just assume people will just do this: 
>> //Poke it, because you must never sleep!!! 
>> setInterval(poke, 0); 
> 
> That's certainly a risk. That said I think the mental model of replacing
> user interaction with a poke is easier to grasp than managing locks and
> states in asynchronous environments.
> 
>> When what they want is:
>> screen.getWakeLock();
>> 
>> //If the use leaves and comes back... 
>> window.onfocus = () => {
>>  //if we've lost the lock
>>  if(screen.wakeLockState === "unlocked"){
>>     screen.getWakeLock();
>>  }
>> }
> 
> Hmm... My perspective was that losing focus on the tab would stop the
> screen wake lock implicitly (i.e. the screen would be free to dim / lock
> again), not that it would require the developer to re-request it. That
> seems like a recipe for bugs.
> 
>>> Is it possible that the browser implementation could detect  
>>> window refresh associated with video or games, thus obviating  
>>> the need for use of an API entirely in some cases? (that still would  
>>> not address the use case of viewing a recipe)
>> 
>> You could, like assuming requestAnimationFrame() or CSS animations
>> could imply this. But it's a bit of an abuse of the API and would tie
>> people to using some particular solution or another. That could become
>> unpredictable and have unforeseen consequences that developers didn't
>> expect ("wtf is causing the screen to stay on?"). It's better, IMO, to
>> let developers just handle this and not add any magic.    
> 
> +1
> 
> Dom
>

Received on Wednesday, 28 May 2014 14:50:49 UTC