Re: Standby API Specification Proposal

On 05 Feb 2014, at 14:59, Dominique Hazael-Massieux <dom@w3.org> wrote:

> 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.

Right. I meant, on the native side developers seem to use these capabilities, and the users expect this type of behavior. I agree most, if not all, of the use cases would work for the Web similarly. The permission model will be important to get right to prevent misuse.

>> 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.

Resource Priorities' lazyload and postpone were probably in the back of my mind when I wrote the above :-)

>> 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?

Let me try: an imaginary setPriority() delivers a hint to the UA of the preferred priority (this can get more granular, but for the sake of simplicity let’s call this the priority of the whole app). The developer defined noPendingTasks boolean signals whether there are pending, time-critical tasks to be performed. Here’s an example which hopefully better explains what I had in mind:

document.addEventListener("visibilitychange", function () {
  if (document.hidden && noPendingTasks) {
    // nothing time-sensitive going on, priority can be lowered 
    setPriority(“low");
  } else if (document.hidden && !noPendingTasks) {
    // time-sensitive pending tasks ongoing, prefer normal priority
    setPriority("default");
  }
  // ...
});

Currently, some browsers [1,2] automatically throttle things like setTimeout/setInterval() in background tabs and/or minimized, invisible windows. The imaginary setPriority() would be a mechanism to opt-out from those optimizations.

>> 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.

True. I think I had the gaming use cases in mind primarily. But for many other use cases bundling this with the fullscreen does not work as well.

> 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

I like this approach as it allows opting out at the time of event, not getting on the way in the normal usage.

Thanks,

-Anssi

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=633421
[2] https://code.google.com/p/chromium/issues/detail?id=66078

Received on Wednesday, 5 February 2014 15:38:07 UTC