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>