On Jan 3, 2010, at 4:24 PM, m...@atopia.net wrote:
My final option, which I like best, is to create an email queue table that can be populated in many ways. For instant actions, I can populate it with triggers, and for passive emails, I can populate it with a cron. Then, I have a single multi threaded perl script read from the queue and generate the emails, and then maintain the queue.
This seems a bit like overkill. After all, queueing email for delivery is exactly the job that sendmail et al were designed to do.
Your typical email message can be templated as a simple sprintf()- style format string, which you can keep in the filesystem, or database, or whatever. There are also plenty of libraries you can use for composition, if you prefer (SwiftMailer and Zend_Mail come to mind).
Then you'll want some code to generate email content, and some code to pass it off for delivery.
The last bit (passing it off for delivery) should probably be more than a call to mail() -- but to start, just write a sensible abstraction that wraps mail(). If you later find you need something more involved (for instance, you want to use an external SMTP server, or you find some real need to write your own queuing system as you described), you can swap out the implementation pretty easily.
I think the most important task is to separate the composition of mail from the queuing of mail cleanly, so that you retain flexibility.
_______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
