Re: [Task Scheduler] scheduling flexibility

I'd like to summarize the discussion so far. There seem to be 3 useful
variations of scheduling:
1. Exact scheduling without a requirement for user notification.
2. Exact scheduling with the requirement to notify the user. The point of
this is that there would be a way for the user to revoke privileges from
spammy apps.
3. Inexact scheduling without requirement for user notification. The system
may throttle apps automatically for any reason, to the point of never
scheduling any tasks e.g. because the user has not opened the app for
months.

There seems to be consensus that the system must have complete control when
inexact scheduling is used. However, Zoltan suggested that the caller of
the API might be given some insight into how the task is scheduled. I'm not
sure this is always possible, as scheduling may depend on unknown future
events.

There should be some policies enforced by the system about who can use
which type of scheduling. This area seems nearly resolved.

I think some additional context is valuable here. For Chrome/Chromium we
are looking into the Task Scheduler API from a "regular web page"
perspective. However, this API has been developed in the context of the
sysapps working group, which assumes greater privileges for API callers.
For example, perhaps the app has been vetted manually. Or if the whole app
can be scanned for the APIs it calls, an app type may be deduced and
privileges assigned accordingly.

As there are many forms a web page or app can take, it seems the exact
permission policy should be implementation dependent. We can classify the
types of scheduling though. I would suggest that type 1 (exact scheduling
without user notification) should be reserved only for the most privileged
apps. Zoltan suggested a telephony app as an example of a highly privileged
app. The other scheduling types require less privilege and might be exposed
on a regular web page e.g. after the user gave permission through a dialog.

Does that capture the discussion so far fairly? Is this something that can
be worked into the spec, or do we need more details e.g. about what the API
would look like?

Regards,

Michael



On Thu, Nov 7, 2013 at 3:01 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

> On Thu, Nov 7, 2013 at 4:42 PM, John Mellor <johnme@google.com> wrote:
> > On Thu, Nov 7, 2013 at 2:15 PM, Kis, Zoltan <zoltan.kis@intel.com>
> wrote:
> >> On Thu, Nov 7, 2013 at 4:01 PM, John Mellor <johnme@google.com> wrote:
> >> > Do you have other use cases for time-sensitive tasks that wouldn't
> >> > involve
> >> > showing a user-visible notification?
> >> >
> >>
> >> Automatic scheduling of a telephony call(back) in case of busy tone.
> >> Tolerates delay in the range of a few seconds, but not in the range of
> >> minutes. There is no notification, the dialer takes care of visuals.
> >
> >
> > If the dialer is the foreground app, then it can just use setTimeout,
> rather
> > than scheduling background tasks. If it needs to be able to do this from
> the
> > background, then perhaps it should require some privileged "consume
> > additional battery in the background" permission.
>
> Handling this from foreground will certainly consume more than with
> background tasks. Speaking about permissions, in the phones I've been
> working with, dialers were not only privileged, but also pre-started
> and even exempt from e.g. cgroup freeze policies, since the need to
> make sure a phone call comes through in all system conditions, at
> least leaving a missed call. Otherwise it was easy to incur loads that
> resulted in missing calls completely. That being said, of course we
> can leave all this stuff to the underlying telephony stack and the OS.
> However, this would be a nice usability addition (at a known /
> measurable cost).
>
> >
> >> Similar use case is (optional) automatic re-sending of failed messages
> >> on protocols that do not support re-sending from a server.
> >
> >
> > Since the app doesn't know when an internet connection will next be
> > available, wouldn't this be better handled by an inexact scheduled task,
> > where the browser can wait till the network is available?
> >
> > Or, better yet, we should introduce a separate browser API that lets you
> > request a long-running up/down-load be performed in the background, with
> > automatic retries (and resuming if the device reboots). Then the browser
> can
> > handle such use-cases with a lightweight single-purpose process, rather
> than
> > having to periodically wake up the entire web runtime just so you can
> poll
> > the network from JS.
>
> Fair enough.
>
> >
> >> Scheduling network connection attempts.
> >
> >
> > Ditto.
> >
> >> Other cron-like scheduled jobs (expirations, things requiring action
> >> from user, etc), which when activated, need to be in [close-to] exact
> >> time. Could these be done via calendar events?
> >
> >
> > Things requiring action from the user presumably already show
> user-visible
> > notifications. I'm not sure what exactly you mean by expirations - are
> they
> > really time-critical?
>
> I meant when e.g. a license to do something needs to be
> [automatically] renewed, but that can be solved from foreground, since
> it's likely bound to user-launched operations.
>
> Regards,
> Zoltan
>