Re-thinking one-off jobs and cron jobs

If you've ever configured a schedule task (aka cron job) for CiviCRM, you know the routine. You have to look up the username and password for a user in your database that has database permissions, you have to find a really long mess of characters known as your site key, you have to find the proper name of the job you want (like UpdateAddress.php or civimail.cronjob.php) and then you must string them all together in precisely the right way to make the cron job. What a tedious drag. To lay the ground work for the Consolidated Cron Make it Happen, which will make all this much easier to setup, we're first doing some major re-organizing of the underlying code. Currently, all of the code for running these tasks are independently stored in one-off scripts in the bin directory. This organization makes it very difficult to run the code in different contexts. For example, if you are using drush, it would be convenient to be able to fire off any of these jobs with a drush command. Or, it would be nice to be able to just run a command from the command line without having to lookup your site key and copy and paste a username and password (if you already have file system access, authenticating with a username and password is superfluous). Because the existing scripts are hard-coded to require certain parameters and expect to be executed only in certain contexts (which vary between the scripts), this need has up to now been un-met. So... how do we go about re-organizing the code to accomplish this feat? Tim helped remind us of the lesson we learned at CiviCon: "Use the API!" The CiviCRM API is designed to provide a simple and consistent interface for performing complex tasks. It can be accessed via the command line and via the web (not to mention via jquery and smarty although we don't suggest running cron jobs this way). For Civicrm 4.1, we plan to replace all the scripts currently in the bin directory except cli.php. cli.php will take command line arguments that specify which task you want to run and it will, in turn, call the API to perform that task. Want drush? No problem. We'll be updating the CiviCRM drush include file to provide commands for each job (which will, in turn, call the API to perform them). And, of course, we won't forget the web - as most users still call their cron jobs via wget over http. Eventually we'll provide instructions for how to construct a wget command that uses the API REST interface. We may need to work out some authentication issues before that is working - if that's the case we'll provide a transition job.php script designed to be called via the web until we have it all worked out.

Comments

Will this effort simplify scheduling various CiviReport instances?

Also, under this new planned structure how many CRON jobs will a typical CiviCRM installation need?