Re: [Task Scheduler] scheduling flexibility

On Wed, Nov 6, 2013 at 2:11 AM, Michael van Ouwerkerk
<mvanouwerkerk@chromium.org> wrote:
> Resending for John. He just switched to a new account and it's stuck in
> moderation.
>
> Thanks for all replies so far. I'm very interested in exploring John's
> suggestions further.
>
> Regards,
>
> Michael
>
>
> On Tue, Nov 5, 2013 at 2:26 PM, John Mellor <johnme@google.com> wrote:
>>
>> Actually, I think we might need to go further than this. Allowing web apps
>> to request to be woken up with precise scheduling seems very dangerous from
>> a battery life perspective. Would it be possible to split this API into two
>> use cases?
>>
>> 1. An API for precise scheduling, which *requires you to show a
>> user-visible notification* to prevent developers from abusing it. For use by
>> calendar notifications, alarm clocks, etc. Could be an extension of Web
>> Notifications.

IIUC, this is standard Web Notifications but delayed according to a
developer-supplied DOMTimeStamp. I like this a lot.

Anything further I have missed in this proposal? e.g. is there any
intention to run scheduled tasks once this DOMTimeStamp is met and/or
when the Web Notification itself is invoked by the user?

>>
>> 2. An API for inexact scheduling (e.g. background syncing). For example,
>> instead of asking to be woken up at a specific DOMTimeStamp, you would just
>> give an optional minimum time delay; the system would guarantee not to wake
>> you up before that, but would choose any convenient moment afterwards. Most
>> apps would just choose the smallest time delay we offer them (which is fine,
>> as the convenient moment mechanism would throttle them), but sometimes an
>> app knows that there's no point in running until some point in the future,
>> which is when they would provide a non-zero minimum time delay.
>>
>> Possible heuristics that the system might use to decide what is convenient
>> time for background execution include:
>> - batching requests together with other apps
>> - being on WiFi
>> - being plugged in to a charger
>> - the screen being on (or device being awake for some other reason)
>> - the network being active
>> - the user not being asleep
>> - learning at what times of day each app gets used, and prioritizing
>> syncing etc shortly before the app is likely to be used
>> - learning in what locations each app gets used, similarly
>> - how recently/frequently the app has been used
>> - how recently the device was last used
>>
>> Of course the heuristics would be implementation-defined, so
>> implementations can optimize battery life without having to update the spec
>> each time.

Should developers also be able to schedule background tasks for non
time-based triggers e.g. allow task scheduling for the next time their
device is 'idling' or 'plugged-in' or 'online' also? i.e. run my
background task when the device next has a connection to the Internet
otherwise _indefinitely_ delay its execution until that condition is
met.

It may also be good for user agents to be able to throw UA-defined or
developer-defined timeouts and other errors against a given scheduled
task and for web-apps to be able catch such scheduled task error and
timeout events. These events would need to be delivered back to the
web app at a time chosen by the UA along the same lines as the
heuristics identified above. Or perhaps timeout and error events
should occur silently (which removes the need to wake up the web app
just to inform it it failed. Kind of cruel, perhaps).

br/ Rich

>>
>> Thanks,
>> John
>>
>>
>> On Tue, Nov 5, 2013 at 1:35 PM, Michael van Ouwerkerk
>> <mvanouwerkerk@chromium.org> wrote:
>>>
>>> How do people feel about allowing for scheduling flexibility in the Task
>>> Scheduler API? The goal of this feature would be to save battery power. If
>>> the system has flexibility about when to precisely run a task, it could
>>> batch multiple tasks together, or only run tasks when the device is awake.
>>> This way, we could avoid waking up devices too frequently.
>>>
>>> Some use cases require precise scheduling e.g. an alarm in the morning,
>>> or a cooking timer. But there are many tasks that are much less time
>>> sensitive, these could be scheduled flexibly e.g. syncing a news feed or
>>> auto-updating to a new version.
>>>
>>> Any comments? My apologies if this issue has been discussed previously.
>>>
>>> Regards,
>>>
>>> Michael van Ouwerkerk
>>>
>>
>

Received on Tuesday, 5 November 2013 17:10:06 UTC