scheduling1Add my vote for this tag create new tag
, view all tags
I've had several requests now from users of the ActionTrackerPlugin and the FormQueryPlugin to be able to control notification schedules from a TWiki page. It doesn't really make sense to do this in isolation for these plugins, when the same technology would be useful elsewhere.

The basic idea is to run a single cron at regular intervals that would invoke a script in the bin directory.

This script would read a TWiki page containing cron schedule information and the names of pages containing notification information.

For example, our cron could be:

* * * * * * cd /hugedisk/twiki/bin && ./cron ../data/MyWeb/CronSchedule
The cron schedule page would contain something like this:
| *Schedule* | *Entry point* |
| Every 2 days | TWiki::Plugins::ActionTrackerPlugin::ActionNotify:actionNotify |
| Every day | TWiki::Notify::allWebs |

The entry point given in the cron page would be eval'd to return a hash { 'email'=>..., 'message'=>... } which would then be processed to generate emails. Note that one of the advantages of this approach is that mails from ALL sources (webchanges, action notifications, task notifications etc) could all be rolled into a single spam message.

-- CrawfordCurrie - 10 Feb 2004

i did a double take on this..

you want to kick my server every minute? get stuffed. no way.

umm, he said "at regular intervals", which, presumably, could be at any measure of time: minutes, hours, days... etc.

  • no - * * * * * in the crontab is run cron every minute to see if something needs doing. this hits the HD (really badly)

I want to work on letting my servers sleep when all the employee's go home (a dynamic time frame),

-- SvenDowideit - 10 Feb 2004, -- MattWilkie - 11 Feb 2004

I think the idea is good in concept, even if a minutely check is a bit too much.

I'd say just modify the crontab entry to run the unified script hourly. I don't know why you'd care about an hourly hit to the server, since that's a miniscule amortized load. Also, hourly notifications should be sufficient, especially if some built-in method for immediate notification is added as well. IE, the user's choices are either "tell me right away, every time something happens" or "tell me on some multiple of hourly about everything that's happened since the last notification". Also, you might consider making the system a lot more flexible - adding a framework for notification methods other than e-mail (like IM's), and adding some way of templating the resulting notifications, presumably also keyed to the method in use. (E.g. for immediate notification by e-mail, a topic diff might be nice, but for IM notification I just want to know which topic was updated.)

Also, that should just be a subsystem of the CronCentre. The script also needs to be able to handle periodic tasks that do things other than generating messages; WebStatistics updates come to mind.

But that's all details, and can probably be worked out once a framework is put in place.

-- WalterMundt - 11 Feb 2004

Don't get hung up on the stars! I only typed five stars because I couldn't remember which field was hour; personally I'd want the cron to run once a day, at a down-time that doesn't hit the backups - but that's up to each individual installation.

Somehow the script has to know when it was last run. I thought of feeding it the cron schedule, but that's unreliable; just because cron tried to run the job on a schedule doesn't mean it succeeded, so the script has to maintain it's own record of the last successful run. If it does this, then "every day" gets interpreted as "if the last run was >=24 hours ago, do it again".

The schedule names I was thinking of run something like this:

every 4 hours
every 5 days 3 hours 4 minutes 10 seconds
every 0 minutes

In each case, the schedule is only possible if the cron is run frequently enough to detect the time shift. If the above schedule only got cronned every 6 days, then all the jobs would run each time the cron ran. If the cron ran daily, then the first and third would run once on each batch, and the second on every 6th. And so on.

Walter, good point; I had been thinking about mailing only. Other jobs can of course be handled the same way. The "return a hash" method is the way I did this in the FormQueryPlugin, so I was thinking the code from there could be reused. The idea of using it to IM is an interesting one; how would that work?

FYI the FormQueryPlugin already supports templating notifications; the reason I didn't mention it is that I felt it would require too many changes to the other notification entrypoints to get them to conform to that methodology.

BTW to support non-HTML mail the hash would have to return { email=>... html_message=>... plain_text_message=>... }.

-- CrawfordCurrie - 11 Feb 2004

I was considering this for a long time. TWiki moves towards an ApplicationPlatform, so it needs to provide an infrastructure for handling scheduled events. Rough spec proposal:

  • As part of the installation a cron (scheduled task on Win) is installed, which calls a scheduler script in a fixed interval, like once a minute, which is one tick unit. It should run as the Apache user.
  • The Plugins implement a new scheduledIntervalHandler that gets called for each tick by default
  • At init time, the Plugin can set a different schedule(s) down to the granularity of the tick unit with a new FuncDotPm function

I think it is time for FeatureTrackingInDocumentAndThreadMode of this topic.

-- PeterThoeny - 12 Feb 2004

Peter, that sounds good. But, would plugin writers prefer a more sophisticated service, e.g. run once a day at this time? Otherwise, many plugin writers will have to reevent the wheel. Still, could offer basic facility and then add to it later.

-- JohnTalintyre - 13 Feb 2004

You are right. I guess I made a silly suggestion about the Plugin init time. Crawford's approach sounds more feasable. What about security? It sounds kind of scary to be able to list function name calls in a TWiki page.

Crawford, agreed on spelling out the times; much better than the cron stars.

-- PeterThoeny - 14 Feb 2004

Re: scripted IM's...they are actually pretty simple. My old ImmediateNotifyPlugin knows how to send Jabber IM's via a CPAN module, and several other, more common, services (ICQ is one iirc) are also available in such a form. Maybe this is not the best idea for packaging with TWiki itself. However, the desirability having the hooks there so that plugins can build new methods of notifying people about the same events is something to keep in mind.

-- WalterMundt

Security: I'm not talking about "any old function" - it would need to be constrained in some way, for example to functions in plugins. I think most plugin authors would be happy with providing an implementation:

public interface Plugin {
   class CronEvent {
      int eventTime; // event time in secs since 1970
      int eventFrequency; // how often the event is scheduled, in secs; for reference only

    * Handle a cron event. A cron event occurs according to the schedule
    * specified in the CronTable topic.
    * @param c the event to be handled
    * @return a vector of hashes, each containing the fields 'email' (which must
    * be a valid email address) 'html_message' and 'text_message' (which are the
    * HTML and text formatted versions of the notification email). This vector may
    * be empty or null if the handler handles notifications in a different way (e.g. IM) or
    * is not a notification service (e.g. a dead topic reaper).
   Vector handleCronEvent( CronEvent c);
(pls excuse the Java; it's much better than perl for writing specs)

Personally I think WebNotify and WebStatistics should be done as plugins BUT <bleat> efficient implementation of such plugins requires a functional, well specified, Store interface published to plugins (so they don't have to grope around in topic files)..... </bleat>

-- CrawfordCurrie - 15 Feb 2004

Any more done on this?

-- MartinCleaver - 09 Apr 2006

Thanks to Raf: http://search.cpan.org/~roland/Schedule-Cron-0.9/Cron.pm

-- MartinCleaver - 09 Apr 2006

That looks very close to being able to be dropped in as a core capability: one single cron / force start to ensure it is running then calls to:

$cron->add_entry("* * * * *",{'subroutine' => \&dispatch,
                                  'arguments'  => [ "first",2,"third" ]});
Looks like it would happily log into TWiki's logging mechanism

-- MartinCleaver - 09 Apr 2006

http://cpants.dev.zsi.at/dist/Schedule-Cron shows it lists only Time::ParseDate v99 as a pre-requisite.

-- MartinCleaver - 09 Apr 2006

Initial implementation of SchedulerContrib: http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item2070

-- MartinCleaver - 10 Apr 2006

TopicClassification BrainstormingIdea
TopicSummary Idea for a untified cron "target" script to trigger all desired periodic behavior.
InterestedParties WalterMundt, PeterThoeny

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2008-09-16 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.