Re: [Task Scheduler] scheduling flexibility

I think a given implementation has the best interest to respect as
much as possible these client hints. The question is what to do with
the wrongdoers.

While we have dumped to idea of explicitly classifying the clients,
implementations could still check the type of apps from the API calls
it is making, infer a profile from that, and update power policy wrt
the app. For this the only input needed is the apps' own preference,
so that is our minimal API (which Chris suggested).

The normal use case is to "believe" the apps asking for highPrecision
are like timer, clock alarm, etc, and believe the UX of those apps
would really suffer if the hint is not respected.

If there are too many apps "lying", the inferred profiles could be
used for selectively overriding hints.

Whether the apps should know hints were overridden, and when could it
possibly happen is a different question. Once we deliver that error,
we are already out of sleep, and could as well respect the hint from
the first place. Or does the implementation know if in the scheduled
time there would be a preemption / delay before the next wakeup and
could it push an error before the time expires with a hint to the app
about the rescheduling details, so that the app could decide about
dropping/accepting it? That depends on other apps, too, and on other
system conditions (low-battery mode, etc).

In practice, what range of delay do we expect when hints are
overridden? I don't expect more than a second anyway for
'highPrecision' apps, which should be OK even for the listed apps,
alarm, calendar, background timer, etc.

Should we specify such delay range in the doc, at least for high precision?

Regards,
Zoltan


On Tue, Nov 12, 2013 at 2:08 PM, John Mellor <johnme@google.com> wrote:
> Skipping the user notification variant for now seems reasonable - it would
> probably be best to integrate that into a v2 Web Notifications API.
>
> However I'm worried about highPrecision serving as a hint. If your app needs
> highPrecision, it's often essential that the timer happens at that exact
> moment, and inexact scheduling often wouldn't be useful. Hence I'd rather
> have add(...) throw an error if you request highPrecision and it gets denied
> (the app can of course catch this and add a non-highPrecision alarm if that
> would be good enough). This should be easy, since add already returns a
> Promise that can fail with QuotaExceededError or UnknownError; we just need
> to add a new HighPrecisionDeniedError.
>
> As for adding a boolean, perhaps it would be clearer to have "addExact" and
> "addInexact"?
>
>
> On Tue, Nov 12, 2013 at 8:50 AM, Michael van Ouwerkerk
> <mvanouwerkerk@chromium.org> wrote:
>>
>> I like Christophe's API proposal. I recognize that the variant with user
>> notification has some unresolved dependencies and might be difficult to
>> adopt right now. Web Notifications has some open issues and does not have
>> full browser support yet, especially not on mobile. So that would not be a
>> trivial dependency to add.
>>
>> Regards,
>>
>> Michael
>>
>>
>> On Tue, Nov 12, 2013 at 2:43 AM, Kenneth Rohde Christiansen
>> <kenneth.christiansen@gmail.com> wrote:
>>>
>>> +1
>>>
>>> On Nov 12, 2013 12:34 AM, "Christophe Dumez" <ch.dumez@sta.samsung.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> My proposal would be to add a 'highPrecision' boolean to the Alarm
>>>> interface that the client app could set to true (false being the default)
>>>> when scheduling the alarm to indicate that precise task scheduling would be
>>>> preferred.
>>>> I also think this flag should merely serve as a hint that the system is
>>>> free to ignore (e.g. to preserve battery life, avoid spamming, ...).
>>>>
>>>> I am hoping this is an acceptable compromise. I am trying to be
>>>> conservative here as I would prefer to avoid major API refactoring at this
>>>> point, unless we really need to.
>>>>
>>>> Kr,
>>>>
>>>> On 11/05/2013 08:36 AM, Michael van Ouwerkerk 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
>>>>
>>>>
>>>> --
>>>> Christophe Dumez - Samsung Telecommunications America
>>
>>
>

Received on Tuesday, 12 November 2013 12:51:06 UTC