Re: [Task Scheduler] scheduling flexibility

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

Received on Thursday, 7 November 2013 15:01:35 UTC