[Zope] Importable Xron
Loren Stafford
lstaffor@dynalogic.com
Thu, 10 Aug 2000 11:51:20 -0700
From: "Graham Chiu" <gchiu@compkarori.co.nz>
> On Wed, 9 Aug 2000 14:45:58 -0700
> "Loren Stafford" <lstaffor@dynalogic.com> wrote:
> > *This message was transferred with a trial version of
> > CommuniGate(tm) Pro*
> > Xron is alpha-level software, which means (among other
> > things) that it is
> > new, hasn't received a lot of use, doesn't have a lot
> > ready examples, may be
> > lacking documentation quantity or quality. If you want to
> > use Xron in its
> > current alpha state you must be willing to invest a
> > little effort in
> > learning to use the product. For my part, as developer of
>
> I think part of the problem is that there are increasing
> numbers of people with limited Zope knowledge, and an
> overwhelming number of Zope products without any indication
> of how difficult it is to use a particular product.
>
> Perhaps Zope product writers should rate their products with
> a difficulty scale.
I think only the users of the products could do that usefully. Developers
are biased. How about if DC puts a rating form on every product page on
www.zope.org, so that users can vote ;^) (Just kidding, really.)
> And regarding the original question, how difficult would it
> be to modify your Xron product so that the periodicity is an
> attribute of the product rather than having to sub class it?
Depends on what sort of periodicity your application needs -- and therein
lies the problem.
There are so many different needs that a built-in general purpose interface
for specifying periodicity is likely to be at least as complex and hard to
explain as a programmable interface.
Take the Unix command 'cron' for example. I've included its man page below.
Is that easy to understand? No way! Now imagine writing the Python/DTML code
to build a nifty point and click interface to it. Not this boy! Now, if you
or someone else wants to take on the challenge of building a cron-compatible
rescheduler interface, be my guest. I've done my part. You can subclass Xron
DTML Method.
Sure, it would be possible to create a simple property that selects Weekly,
Hourly, or OneTime. ...with maybe a corresponding check-box in the
management interface. As soon as I published a simple system like this, the
requests would start coming for more and more capabilites, and the interface
would grow without control. For example, suppose you want to add Monthly to
that list. Now you have to answer the questions "What kind of month --
calendar or accounting? ... which accounting system?" So, if I were going to
create this kind of interface, I'd do it in a subclass, anyway, so as not to
clutter up the base Xron product with something that is likely to change
frequently.
So how about this: I invite other developers to create rescheduler
sub-products for Xron. If you create a rescheduler product, let me know
about it, and I'll link to it from the Xron product page. Your product could
be a Python product or a ZClass product. There's probably room for something
like "Simple Rescheduler for Xron", which would do Weekly, Hourly, and
OneTime; and "Cron for Xron" which would be a full cron-like interface; and
maybe a product of intermediate complexity. The "Simple Rescheduler" would
make a good first-time ZClass project. The developer would need to know how
to write a ZClass, how to handle PropertySheets in a ZClass, and how to use
DateTime.
Does this sound like a good plan or a bad one? Any takers?
-- Loren
=========
man cron
=========
The format of a cron command is very much the V7 standard, with a
number
of upward-compatible extensions. Each line has five time and date
fields, followed by a user name (with optional ``:<group>'' and ``/<lo-
gin-class>'' suffixes) if this is the system crontab file, followed by
a
command. Commands are executed by cron(8) when the minute, hour, and
month of year fields match the current time, and when at least one of
the
two day fields (day of month, or day of week) match the current time
(see
``Note'' below). cron(8) examines cron entries once every minute. The
time and date fields are:
field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)
A field may be an asterisk (*), which always stands for ``first-last''.
Ranges of numbers are allowed. Ranges are two numbers separated with a
hyphen. The specified range is inclusive. For example, 8-11 for an
``hours'' entry specifies execution at hours 8, 9, 10 and 11.
Lists are allowed. A list is a set of numbers (or ranges) separated by
commas. Examples: ``1,2,5,9'', ``0-4,8-12''.
Step values can be used in conjunction with ranges. Following a range
with ``/<number>'' specifies skips of the number's value through the
range. For example, ``0-23/2'' can be used in the hours field to
specify
command execution every other hour (the alternative in the V7 standard
is
``0,2,4,6,8,10,12,14,16,18,20,22''). Steps are also permitted after an
asterisk, so if you want to say ``every two hours'', just use ``*/2''.
Names can also be used for the ``month'' and ``day of week'' fields.
Use
the first three letters of the particular day or month (case doesn't
mat-
ter). Ranges or lists of names are not allowed.
The ``sixth'' field (the rest of the line) specifies the command to be
run. The entire command portion of the line, up to a newline or %
char-
acter, will be executed by /bin/sh or by the shell specified in the
SHELL
variable of the cronfile. Percent-signs (%) in the command, unless es-
caped with backslash (\), will be changed into newline characters, and
all data after the first % will be sent to the command as standard
input.
Note: The day of a command's execution can be specified by two
fields --
day of month, and day of week. If both fields are restricted (ie,
aren't
*), the command will be run when either field matches the current time.
For example,
``30 4 1,15 * 5'' would cause a command to be run at 4:30 am on the 1st
and 15th of each month, plus every Friday.
EXAMPLE CRON FILE
# use /bin/sh to run commands, no matter what /etc/passwd says
SHELL=/bin/sh
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * * $HOME/bin/monthly
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ...,
everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"
SEE ALSO
crontab(1), cron(8)
EXTENSIONS
When specifying day of week, both day 0 and day 7 will be considered
Sun-
day. BSD and ATT seem to disagree about this.
Lists and ranges are allowed to co-exist in the same field. "1-3,7-9"
would be rejected by ATT or BSD cron -- they want to see "1-3" or
"7,8,9"
ONLY.
Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".
Names of months or days of the week can be specified by name.
Environment variables can be set in the crontab. In BSD or ATT, the
en-
vironment handed to child processes is basically the one from /etc/rc.
Command output is mailed to the crontab owner (BSD can't do this), can
be
mailed to a person other than the crontab owner (SysV can't do this),
or
the feature can be turned off and no mail will be sent at all (SysV
can't
do this either).
AUTHORS
Paul Vixie <paul@vix.com>