W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2014

Re: Standby API Specification Proposal

From: Ilya Bogdanovich <bogdanovichiy@yandex-team.ru>
Date: Wed, 4 Jun 2014 12:28:27 +0400
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, Dominique Hazael-Massieux <dom@w3.org>, Frederick Hirsch <w3c@fjhirsch.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Mats Wichmann <m.wichmann@samsung.com>
Message-Id: <D19413A4-D7CF-43E7-AE23-731D37EF3A45@yandex-team.ru>
To: Marcos <marcos@marcosc.com>
Hi Marcos,

I’ve placed a pull-request on github, to be more clear with my suggestions:


On 29 мая 2014 г., at 21:21, Marcos <marcos@marcosc.com> wrote:

> On May 29, 2014 at 1:08:39 PM, Ilya Bogdanovich (bogdanovichiy@yandex-team.ru) wrote:
>> Hi Marcos,
>>> This could also happen with the GC-based model, as the object needs to be kept alive and  
>> explicitly deleted to be useful.
>>> this.wakeLock = screen.getWakeLock();
>>> function youCanSleepAgain(){
>>> doSomething(); // exception thrown
>>> delete this.wakeLock;
>>> }
>> That’s true, but choosing between two possible errors - "app should not dim but it does",  
>> and “app should dim but it doesn’t” - the second one seems more harmful to me.
> Yes, I agree. 
>>> Anyway, the point is that there are lots of ways to manage this - and the underlying OS  
>> may give the user means to override allowing apps stopping the screen from going to sleep  
>> or dimming.
>> I didn’t mean modal dialog, but of course browser or OS should have a chance to notify user  
>> of such web app behavior and allow him to reject this. And it’s better to notify him before  
>> the action starts, than interrupting process when OS would try to dim the screen for the  
>> first time.
> Ok, cool. Just wanted to make sure. It seems we are pretty much aligned in our thinking then. 
Received on Wednesday, 4 June 2014 08:29:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC