soliciting opinions about potential new cron/at features.

[Rob Browning <rlb@cs.utexas.edu>]

(Before I make any more noise about this (like suggesting it to the
 upstream authors), or put any work into hacking it myself, I'd like
 to see what others think about these two suggestions.  Are they
 reasonable ideas, etc.)

While working on GnuCash, and while thinking over the past months
about some other projects I'm interested in (for my own uses), I've
run into the same scheduling problems several times, and I think
perhaps I've come up with a generally useful solution, presuming that
it would be possible/desirable to add (normally ignorable) new
features to cron and at).

Cron:
=====

The problem: take GnuCash as an example.  I'd like to add a nice
interface for "automatic transactions", so you can say things like
"record my rent payment at the first of every month into the checking
register" and just have it happen automatically.  Now I could try to
write some kind of mechanism to handle this internally, but I'd
quickly get stuck (especially if I wanted things to happen even when
GnuCash wasn't running) into re-implementing cron -- a waste of both
time and system resources.  However, as cron now stands, I can't
easily use it either because these kinds of Gnucash commands need to
be added to the *user*'s crontab, not the system one, and I
*definitely* don't want to do any automatic editing of the user's
crontab.  That sounds like a stellar way to get yourself lynched if
you screw something up.

Suggested solution: add the idea of "independent sections" to cron at
the user level.  Conceptually I'm talking about something similar to
the Debian cron.d directories.  You'd add a --section (or -s) argument
to crontab that would specify "which" user crontab you meant, so you
could do something like this:

  # list the GnuCash crontab
  $ crontab --section GnuCash -l

  # replace the Gnucash crontab
  $ cat somecommands | crontab --section GnuCash -  

etc.

I would also be nice if crontab would return a status value indicating
any failure to parse a given input crontab.

With this approach, GnuCash would have it's own user-level crontab to
monkey with.  I suspect this feature could be added fairly easily
using the cron.d/ infrastructure that Debian already has.

It might also be nice to have some separation between section names
reserved for the user vs those for apps.  i.e. perhaps say that all
section names starting with app: are reserved for the use of
applications, so for GnuCash we'd have --section app:GnuCash.
Alternately, there could be two different options --app-section and
--section, or whatever.

At:
===

I'd like eventually to do something similar for at, except in at's
case, I'd like to have it (upon request) return a completely unique id
for a job submission (perhaps you would specify --uid when you invoke
it) so that applications that want to use at to schedule future
actions have some way to talk about that job later (to list or remove
it).  Right now you only get an integer that I don't think is
guaranteed to be unique across invocations/removals/reboots, etc.

Thoughts?

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930