From: "Graham Chiu" <[EMAIL PROTECTED]>
> On Wed, 9 Aug 2000 14:45:58 -0700
>  "Loren Stafford" <[EMAIL PROTECTED]> 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, 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

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

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
     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
     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
     two day fields (day of month, or day of week) match the current time
     ``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
     command execution every other hour (the alternative in the V7 standard
     ``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.
     the first three letters of the particular day or month (case doesn't
     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 %
     acter, will be executed by /bin/sh or by the shell specified in the
     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

     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,
     *), 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.

     # use /bin/sh to run commands, no matter what /etc/passwd says
     # mail any output to `paul', no matter whose crontab this is
     # 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 ...,
     5 4 * * sun     echo "run at 5 after 4 every sunday"

     crontab(1),  cron(8)

     When specifying day of week, both day 0 and day 7 will be considered
     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

     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
     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
     mailed to a person other than the crontab owner (SysV can't do this),
     the feature can be turned off and no mail will be sent at all (SysV
     do this either).

     Paul Vixie <[EMAIL PROTECTED]>

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to