RE: Standby API Specification Proposal

Anssi, Dom,
Idle API is among the Phase 2 items for the SysApps Working Group - http://www.w3.org/2012/sysapps/.  I think this kind of proposal would be better discussed in that WG, since an API will be defined for idle user notification already.

-Giri

-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Wednesday, February 05, 2014 4:59 AM
To: Kostiainen, Anssi
Cc: Dariel Marlow; <public-device-apis@w3.org>
Subject: Re: Standby API Specification Proposal

On mer., 2014-02-05 at 11:59 +0000, Kostiainen, Anssi wrote:
> > Now, for some good news:
> > * your document include use cases which seem pretty reasonable and 
> > that I can guess others would find interesting as well
> 
> The use cases and requirements described seem to be addressed on the 
> native side of things on major mobile platforms and similar APIs are 
> used widely e.g. by games (I have no data though to support my hunch).
> So this would be bridging the gap, if this type of functionality is a 
> good fit for the Web, that is.

It felt to me that the use cases were not particularly on the native-side of things: watching a video, navigating (say with Google Maps), or playing an accelerometer-based game seem classical use cases for Web apps.

> Looking this from another angle: do we have a reasonable use case for 
> a web app be able to explicitly inform the UA that it *is fine* to 
> optimize resource consumption? Currently, the visibility state of the 
> page is the only hint exposed to the web content, and it cannot be 
> programmatically altered naturally.

Yes, I think page visibility is the only hook available; Resource Priorities is another upcoming hook for network usage.

> Browsers use various heuristics to identify inactivity (e.g.
> visibility state), but these heuristics do not always work, and the 
> web app may want to explicitly let the UA know it is not doing 
> anything performance critical.

That train of thoughts might be worth exploring; could you maybe describe in more details what you have in mind here? i.e. when would a web app give such a hint, and what a UA might do with it?


> Just an idea, this could be tied to the Fullscreen API. That is, a 
> user could request a page to be fullscreen and "always on”. We could 
> reuse the permission model.

I had the same idea while thinking about it, but have since moved away from it; while there are likely many cases you'll want to ask for the two together, there are also many cases where you wouldn't. Also, none of the existing APIs bundle the two together.

On the permission front, my rough thinking of a probably workable approach would be:
* no user consent asked when the Web app asks for “always-on”

* at the time when the screen would by default go blank, the UA informs the user that the Web is using an “always-on” mode (e.g. via an infobar), and let the user forbid it;

* the UA would probably adjust that behavior depending on the remaining battery (i.e. simply not grant that right when battery is too low, or prompt the user again if the battery goes down, etc)

* likewise, the prompt/infobar might go away completely if the device is charging

Dom

Received on Wednesday, 5 February 2014 14:23:02 UTC