- From: Frederick Hirsch <w3c@fjhirsch.com>
- Date: Wed, 28 May 2014 08:37:03 -0400
- To: Marcos <marcos@marcosc.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Dominique Hazael-Massieux <dom@w3.org>, Mats Wichmann <m.wichmann@samsung.com>
- Cc: Frederick Hirsch <w3c@fjhirsch.com>
Regarding the three proposals on the list related to a possible standby API [1], I think what was noted in the Chromium log is important [2]: "Applications can receive other forms of input than touch, whereas only touch will prevent the device from sleeping after N seconds” 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..) it seems Dom’s poke proposal gets at the idea of allowing programmatic notice of input other than touch, avoiding the issue of locks 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) regards, Frederick Frederick Hirsch, Nokia Chair DAP @fjhirsch [1] http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0001.html (Dariel Marlow) Dom Proposal http://lists.w3.org/Archives/Public/public-device-apis/2014May/0049.html Marcos alternative proposal http://lists.w3.org/Archives/Public/public-device-apis/2014May/0054.html [2] https://code.google.com/p/chromium/issues/detail?id=257511 On May 26, 2014, at 10:14 AM, Marcos <marcos@marcosc.com> wrote: > > > On May 23, 2014 at 11:59:22 AM, Dominique Hazael-Massieux (dom@w3.org) wrote: >>> >> Based on a subsequent thread in the brand new specifiction forum >> [1], I >> have drafted a very rough proposal that would fulfill the use >> cases that >> have been discussed: >> http://w3c.github.io/screen-wake/navigator_poke.html >> (see also >> https://github.com/w3c/screen-wake) >> >> It is pretty different from the similar APIs in this space: >> https://github.com/w3c-webmob/web-api-gap/blob/master/features/screen-wake.md >> (which means it's probably not the easiest path to convince implementors) >> >> Dom >> >> 1. >> http://discourse.specifiction.org/t/allow-developers-to-control-wake-lock-aka-disable-auto-dimming/ > > Following Dom's lead, I've put together an alternative proposal: > https://github.com/w3c/screen-wake/blob/gh-pages/screen_requestWakeLock.md > > It be great if other could do the same, then we can debate the merits of each. > > > > > >
Received on Wednesday, 28 May 2014 12:37:38 UTC