Re: [Task Scheduler] scheduling flexibility

The thing to keep in mind with Geolocation is that there is always some
imprecision. It's just not possible to be infinitely accurate. Arguably
TaskScheduler can be, and some use cases need it to be. In Geolocation
there is also a trade-off between timeliness (a wifi scan might be faster
than a GPS lock) and accuracy. This trade-off does not necessarily exist in
TaskScheduler: the system most likely knows for sure whether exact
scheduling is permitted for a given caller.

/m



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

> On Tue, Nov 12, 2013 at 4:27 PM, John Mellor <johnme@google.com> wrote:
> > 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. 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, 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?
>
> Yes, these are the default low priority use cases, which do not
> specify the 'highPriority' flag, therefore won't get any errors on
> hints override anyway.
>
> The original question was what to do with high priority apps, since
> they want to be exceptions from the general rule, and then what to do
> with possible wrongdoers.
>
> My point was that even if we don't extend the API to support raising
> errors on hints override, probably won't considerably change the UX of
> the high priority apps, therefore I conclude we don't really need the
> error support in the API, and Chris' proposal is good enough. However,
> it is not a big deal to implement that error if you need it (just that
> I was not convinced it's really useful, and in addition it takes a big
> deal of explanation about the possible circumstances of delivering
> it).
>
> >
> >> Should we specify such delay range in the doc, at least for high
> >> precision?
>
> But again, should we mention a delay range in the spec for high priority
> apps?
>
> Thanks,
> Zoltan
>
>
> >>
> >> 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
> >> >>
> >> >>
> >> >
> >
> >
>