Re: [Task Scheduler] scheduling flexibility

Sorry for top posting, now it is more consistent.

The view difference is whether you consider this as a "lock" i.e. the
app dictating the terms (which seems to be your view), or as a system
decision (which is my view).

In my view, it is the system which should decide in this matter,
whatever the app wants, and it is the app which should conform. If the
app does not tell anything, the platform decides anyway and the app
will just not have the way to know it. That is implicit policy, and
does not need any API.

Implicit policy could also be done on an app classification based on
what resources  / features does the app use. That would also be useful
for deducing app priorities for handling other shared resources like
audio, video, processor, network, etc.

If the app wants an explicit policy (i.e. telling preferences, and
getting the actuals), that requires the API I was talking about.

I would definitely want to avoid the apps orchestrating (i.e. locking)
things, since they don't know about other apps, priorities and system
preferences. Also, it makes their life much easier if the user agent
handles this.

Best regards,
Zoltan

PS in the meantime response came from Michael, so including John.


On Tue, Nov 5, 2013 at 5:04 PM, Kenneth Rohde Christiansen
<kenneth.christiansen@gmail.com> wrote:
> I would put it the way, that the app might know, but the majority will not
> care and not set any value (or set the wrong one), which disallows us from
> doing smart optimizations.
>
> In the case the user don't know or don't care, it should default to
> something that we can optimize smartly... Basically you need to opt-out of
> the optimization is you really need to, not opt-in to one, because that just
> rarely happens (judging from the rest of the web and scrolling optimizations
> etc).
>
> Just define that the events might not be totally precise due to batching,
> but if they need to be the user can say so, but that might negatively affect
> battery usage. Just like the geolocation API has a way to opt-in to more
> precise data.
>
> Kenneth
>
>
> On Tue, Nov 5, 2013 at 3:56 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>>
>> On Tue, Nov 5, 2013 at 4:51 PM, Kenneth Rohde Christiansen
>> <kenneth.christiansen@gmail.com> wrote:
>> > You really want it the other way around. Users should tell when they
>> > don't
>> > tolerate such a delay.
>>
>> That is a subset, so it is the same way, not the other way around :).
>>
>> >
>> > You can not expect the users to do the right thing, so let's make the
>> > default what makes the most sense for the platform.
>>
>> The app knows what kind of delays it can work with, the platform does
>> not know it, so we need a way the app tell it. On the other hand, it
>> is good if the app could find what the user agent has decided.
>>
>> Whichever way - I trust Chris on this :).
>>
>> Regards,
>> Zoltan
>>
>> > On Tue, Nov 5, 2013 at 3:43 PM, Kis, Zoltan <zoltan.kis@intel.com>
>> > wrote:
>> >>
>> >> On Tue, Nov 5, 2013 at 3: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
>> >> >
>> >>
>> >> Valid point. In my view, the use case could be formulated like this:
>> >> - a given platform or device policy / setting may support "scheduling
>> >> heartbeat" (similar to IP heartbeat)
>> >> - applications should have means to tell the user agent if they can
>> >> tolerate small delays (and how much. in terms of lower bound, desired,
>> >> upper bound) in task scheduling, let's call this "request"
>> >> - the user agent should have means to tell the application the
>> >> "response" about whether it can respect the request or not, or if it
>> >> can respect it with changes in requested max delay. The app can then
>> >> adapt to this.
>> >>
>> >> That would mean introducing a function call (with the range expressed
>> >> as parameters), and a new event (with actual max delay as parameter).
>> >>
>> >> Regards,
>> >> Zoltan
>> >>
>> >
>> >
>> >
>> > --
>> > Kenneth Rohde Christiansen
>> > Web Platform Architect, Intel Corporation.
>> > Phone  +45 4294 9458 ﹆﹆﹆
>
>
>
>
> --
> Kenneth Rohde Christiansen
> Web Platform Architect, Intel Corporation.
> Phone  +45 4294 9458 ﹆﹆﹆

Received on Tuesday, 5 November 2013 15:15:03 UTC