Re: [Task Scheduler] scheduling flexibility

On Tue, Nov 12, 2013 at 12:50 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

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

We're considering implementing this API In low-privileged contexts, like
frequently-visited drive-by web pages, or web pages that have merely
been bookmarked
to the device's home
screen<http://developers.google.com/chrome/mobile/docs/installtohomescreen>.
In such contexts, if we implemented this API we would probably never allow
highPrecision even with permission dialogs/infobars (instead we'd wait for
a future version of Web Notifications to allow setting a high precision
delay).

And using the kinds of heuristics I suggested
earlier<http://lists.w3.org/Archives/Public/public-sysapps/2013Nov/0039.html>,
inexact scheduling might be delayed by 24 hours or longer until e.g. the
device is next on WiFi and/or plugged-in to a charger. Or we might only
schedule infrequently used web apps once a week or less.

Are these use cases that Task Scheduler is interested in supporting?

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