rewrite jobs scheduling

[GoogleCodeExporter]

more a todo note then a real issue :)

current jobs system works and provides a pretty good solution for (simple)
job scheduling, but it uses a lot of copy-pastes code from django (which is
dirty) and some people would like to have more extensive scheduling.

the rewrite will/should be fully backwords compatibily in terms of jobs
classes.

Original issue reported on code.google.com by v.oostv...@gmail.com on 23 Jun 2008 at 7:05

[GoogleCodeExporter]

I'd be interested in helping with this, but it would be good to see some 
specifics of
what you want to happen.

I, for one, would like to see:

1) the signal support expanded (like the addition of a convenience decorator 
such as
@job(when='hourly'));

2) in line with #1: the use of jobs.py files next to models.py and admin.py 
(this
would make jobs blend-in more nicely with Django's style);

3) the ability to use arbitrary when-tags (like 'quarterly' or '15-minutely'), 
which
may or may not permit cron timing strings to be associated with them; and

4) a crontab extension command for dumping a series of lines that can be 
included in
a user's crontab (may use the cron timing strings from #3).

Support for the existing Job classes can be provided on top of the model I'm
suggesting.  I would suggest minor alterations, though, like the following:

1) scan files for subclasses of BaseJob instead of just classes named Job;

2) set the default 'when' group of a BaseJob according to its containing 
module, if
standard monthly/weekly/daily/hourly (it took me a while to figure out that 
putting a
job in the 'hourly' directory was not enough to make the job hourly); and

3) fail loudly on a bad job file (I must say it is quite irritating to debug 
bugs
that manifest themselves as utter silence when I "runjobs hourly"), or at least
complain and continue.

These alterations, as described, should be compatible with your goal of
backwards-compatibility.

Original comment by jbalo...@gmail.com on 6 Aug 2008 at 4:02