[nycphp-talk] email system for website
tim_lists at o2group.com
Sun Jan 3 16:42:43 EST 2010
On Jan 3, 2010, at 4:24 PM, matt at 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.
More information about the talk