It's basically an HTTP crontab replacement that does a bit more than crontab. Crontab is very regular where as crondom can be irregular. For instance, When there is a lot of events to handle, you want polling to be very fast (1 second resolution). However, where there are very few events, you want the polling to be very slow (every 2 minutes). crondom enables this use case by enabling the developer to determine how long to wait until the next hit.
You can also break up a cron job into # of clients. This enables you to process reasonable large # of clients by giving each client a URL to go with rather than doing the work at the moment. For instance, you want to pull 1000 user twitter feed every day. Well, if it takes 1 second, then you have 1000 seconds of work for the script, or 16 minutes. Most developers are forced to live within 30 seconds per request.
In this same scenario, what happens when it fails for user 377? what happens for 378? Handling errors is not always straight forward especially from a business case. Ideally, crondom will enable us to graph for failure cases (coming soon) and isolate which part of the cron task failed.
You can also break up a cron job into # of clients. This enables you to process reasonable large # of clients by giving each client a URL to go with rather than doing the work at the moment. For instance, you want to pull 1000 user twitter feed every day. Well, if it takes 1 second, then you have 1000 seconds of work for the script, or 16 minutes. Most developers are forced to live within 30 seconds per request.
In this same scenario, what happens when it fails for user 377? what happens for 378? Handling errors is not always straight forward especially from a business case. Ideally, crondom will enable us to graph for failure cases (coming soon) and isolate which part of the cron task failed.