Re: [Task Scheduler] scheduling flexibility

This fits pretty much with my thinking. I like it.

Kenneth


On Tue, Nov 5, 2013 at 4:11 PM, 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 <http://www.w3.org/TR/notifications/>.
>>
>> 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.
>>
>> 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
>>>
>>>
>>
>


-- 
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆