[eluser]PhilTem[/eluser]
Recently I started using CronJobs in a project for sending out mass mails to a large amount of users.
It was no problem getting the thing set-up within crontab over my server's shell.
But what I am now looking for for my next project: Manage these cronjobs easily via an admin-interface so there is no necessity to use the server's shell anymore (or at least only once). The reason I'd love to have something like this: People should be able to easily add a cronjob but won't have to bother with unix-shells and stuff. So on the admin-interface they only enter the URL (module/controller/method/args1/.../argsn) and set the time, anything else will be handled by the cronjobs-module
I came up with three possibilites on how to implement this, and I wonder, which one would you prefer:
Way 1:
Set up a controller that grabs all to-be-run tasks from a table inside the database and runs every single one of them (depending on when they were last run etc.)
Therefore I'd only need one line within the crontab of the apache-user which should obviously be run frequently - since there may come up tasks the need to be run every minute (don't ask which tasks, just for purpose)
Way 2:
Use the admin-interface to "manually" write the crontab every time we set up another cronjob.
Advantages: Cronjobs are run whenever they are intended to run and it's all managed by the server itself
Disadvantage: More complex implementation of the admin-interface to correctly write the crontab-file
Way 3:
Save all needed cron-jobs inside the database and only write the crontab-file once on cronjob add or edit or delete (i.e. on any change of any cronjob definitions). That's actually a mix of way 1 and way 2.
Since I'm not that into cronjobs yet I'd like to here some of you who feel more comfortable with crons to tell me what they think of any of these ways (or maintain the state as-is and write everything via shell into crontab)?
