Re: [Task Scheduler] scheduling flexibility

On Tue, Nov 5, 2013 at 5:34 PM, Kenneth Rohde Christiansen
<kenneth.christiansen@gmail.com> wrote:
> 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 fully agree it would be difficult. In fact, every platform may
define it in a different way.
For instance Mozilla did it[1], we have done it[2] (that is a
configuration example), and pretty much everyone doing some kind of
resource arbitration has to do it. Whether is this contained in the
implementation is another question. IMO in most cases it could be
deduced from what features the app is (really) using.

But we may say there is a classification (whatever it is), tell the
app what that list is, which will show it to the user, and the user
will select it. It is true that mechanism would be owned by the
implementation and no need to expose an API for it.

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

Wait - having or not separate API's is orthogonal to have app types or not.

To summarize, IMO the simplest is to not have an API at all, let the
system decide.

Next is to do the explicit policy what John suggested (whether with
one or two API's doesn't really matter).

What I suggested, implicit policy based on app type, may be an
implementation detail for the first case.

Regards,
Zoltan

[1] https://wiki.mozilla.org/WebAPI/AudioChannels
[2] https://github.com/01org/murphy/blob/master/src/daemon/murphy.lua
, line 99-105


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

Received on Tuesday, 5 November 2013 15:58:06 UTC