- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Tue, 5 Nov 2013 17:30:53 +0200
- To: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
- Cc: John Mellor <johnme@google.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
On Tue, Nov 5, 2013 at 5: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. Agreed, except that requiring notification may be platform-specific, and it may mean different things on different platforms. As a default it's good. In the real implementations, since you quoted specific app examples, I think it would be good to to this not only based on zero or close-to-zero delay specified (or lock), but also based on categorizing the applications. We have come up with a few app classes from resource scheduling point of view, and these may be possible to be standardized. >> >> 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. I think we have been talking about this one. Actually I think it may be possible to cover this one in the same API as the previous, it's just one extra explicit or implicit information. >> >> 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 Exactly, a given platform may decide on context based on a multitude of inputs, and that is why it should own decisions about this. >> >> Of course the heuristics would be implementation-defined, so >> implementations can optimize battery life without having to update the spec >> each time. We also have the option for an implicit policy based on app type, then the apps don't have to do anything, and we don't even have to define an API, unless we want the app know what happens. Exceptions are quite rare (calendar + alarm clock) to affect battery life from statistical point of view, so these could be respected with relatively little loss. Best regards, Zoltan >> >> 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 15:31:20 UTC