Re: Deploying scheduled jobs with PEAR

On 14/12/09 14:32, Brett Bieber wrote:

I'd submit something to pepr. First the basics like the scheduling scripts to add, remove, and modify scheduled tasks, then work towards supporting the custom roles.

Yep, will do. Thanks for the reply and interest (ditto David/Till/Ken!). Whilst we're thinking about the design, here's an interesting challenge if we do it the way suggested: what if you want to overload a scheduled job? For example, I install Foolib-1.0.0 which has a default scheduled job to do some important task. However, in a particular instance I want to overload that to run it more/less often/not at all. Two possible solutions that immediately come to mind; they are both pretty fundamental to the design: 1. give a unique identifier to each task, i.e. define the scheduled job format to be something like this: footask: * * * * * php /path/to/whatever.php where "footask" is the unique identifier which in theory could be overloaded by a file installed from another lib/application, but the problem there is defining the ordering (i.e. how do you know which file takes precedence? Could be simple filename alphabetic ordering e.g. Foolib installs 00-footask.cron whereas the "overloaded" app installs 50-footask.cron; however this is still a challenge to integrate with per-file postinstall tasks) 2. Do it a completely different way, using classes and code to manage the definitions rather than installing standalone files e.g.: class Foolib_Tasks extends System_ScheduledTask { function __construct() {

    $this->addTask('footask', '* * * * * php /path/to/whatever.php');
    $this->addTask('bartask', '* * * * * php /path/to/somethingelse.php');

} } class Foolib_Tasks_overloaded extends Foolib_Footask { function __construct() {

    parent::_construct();
    // overload footask
    $this->replaceTask('footask', '* * * * * php /path/to/myoverload.php');

    // remove bartask
    $this->removeTask('bartask');

    // special task needed for Foolib in this overloaded environment
    $this->addTask('wibbletask', '* * * * * php /path/to/othertask.php');

} } although this does mean you need to call some kind of kickstart/bootstrap function (via external means) on application install (possibly including discovery of all the relevant classes) which doesn't seem quite so elegant/simple as something integrated into a custom role. Interestingly enough I note that a similar thing has been proposed recently in ZF which takes the "code" approach: http://framework.zend.com/wiki/display/ZFPROP/Zend_Schedule+-+Mark+Corti

This sounds like a really useful feature for full-stack applications - something I might take advantage of myself.

Well, the reason why I'm interested in this is because I manage a significant number of automated full-stack deployments using PEAR where making sure that scheduled jobs get installed correctly is really important and a significant challenge. So, I already have some simple working (used in production) code as part of a quick-n-easy framework for "deploying stuff" called WADF ( http://www.timj.co.uk/computing/software/wadf/ ). This knows how (along with some other things that are outside the scope of the PEAR installer/awkward to do in it) to cleanly add and remove tasks from a Linux cron as part of an application deployment, although it doesn't address the overloading issue above. The point is that I'd quite like to take the code out of WADF and put it in PEAR (whilst making it more powerful at the same time) :-) Tim