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 12:59:22 UTC