Re: Standby API Specification Proposal

On 05/19/14 03:29, Kostiainen, Anssi wrote:
> Hi Dom, All,
> 
> On 05 Feb 2014, at 12:52, Dominique Hazael-Massieux <dom@w3.org> wrote:
> 
> [...]
> 
>> * To justify the cost of going through this, we would want to get some
>> clear interest from others, in particular browser vendors, that they do
>> want to implement such an API.
> 
> There’s now (re)emerging interest in experimenting with such an API in Chrome the browser (not Chrome Apps):
> 
> https://code.google.com/p/chromium/issues/detail?id=372443
> https://code.google.com/p/chromium/issues/detail?id=257511
> 
>> * Firefox OS ships an API with similar goals, navigator.requestWakeLock:
>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.requestWakeLock
>>
>> * likewise, Chrome Apps have a requestKeepAwake API available to them:
>> https://developer.chrome.com/extensions/power.html
> 
> It seems neither of the above experimental APIs seem to address the Chrome's requirements, so yet another API may get implemented.
> 
>> So there are clear precedents in this space, and maybe this thread can
>> serve to gather confirmations that browser vendors would be interested
>> on this; I'll try to gather feedback on this in other avenues, and
>> hopefully you could as well try and get such feedback.
> 
> Dom - I think there’s now sufficient interest for this feature to justify moving this into a W3C working group soon. This is a small addition considering the overhead of rechartering a group, but OTOH it would be pity to leave this feature stranded due to that.
> 
> Thanks,
> 
> -Anssi
> 


Is rechartering even strictly required here?  We already have:

The working group will deliver the following specifications:
...
    An API to react to a device power status

Perhaps the words "react to"  in the charter are chosen very carefully
such that participants only think they've agreed only to an api for
notification of power state changes and not interaction with the system,
but if not interpreted that narrowly, it seems it could fall in the
device power area.

It's been mentioned various systems have this capability natively. To
provide some examples:

On Tizen the underlying "core" device API (at the moment not exposed to
"app store" type public apps, either native or web) has a power api
which includes state locking functionality for this purpose.

===
Overview

This Power API provides functions to lock or unlock the power state of
the system. Power management is normally handled by policies which are
internal to the platform. For example, if there is no user input for a
certain time, the power manager will change to a lower power consumption
state. Fresh user input at this point will cause the power manager to
change the state to normal. The default behavior may be undesirable for
some applications, for example while watching a long video there is
unlikely to be any user input, but it would be very irritating if the
screen display was dimmed, then turned off to save power.

There are three lockable power states: Normal, Screen dim, and Screen
off, and two more that cannot be locked, System suspend and Power off.
===

Android has a similar API:

https://developer.android.com/reference/android/os/PowerManager.html


These are not exposed to browsers, true; but doing so is in line with
the idea of eliminating reasons why "we don't want to do a web app
because it can't do {foo}".  This is pretty much what Anssi said back in
the very beginning of this thread, so sorry if I'm restating :)

-- mats

Received on Monday, 19 May 2014 12:57:23 UTC