Re: [Task Scheduler] scheduling flexibility

Defining app type is hard and many apps do a lot of different things and
the split might not be so easy, ie. it might have many different kind of
tasks which should act differently.

I don't really like such an approach, and I better like separate APIs like
John suggested, especially as the "expensive" one comes with some
downsides, not making it the default choice for developers.

Kenneth


On Tue, Nov 5, 2013 at 4:30 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

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



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