[nycphp-talk] broadcast emailer: is this sane strategy
David Mintz
dmintz at davidmintz.org
Mon Aug 16 17:15:01 EDT 2004
I'm rolling my own broadcast emailer and now that I've already put in way
too many hours on it, I thought I'd check in and see if people think this
overall design is sound.
It's a two-page form. Page one presents them with a form for the body,
subject, and a select menu to choose whether to send this message to
everybody in this MySQL database or just a subset. There's some
validation, then page two lets them proof it, and they can click either
Send to send it (duh!), or Edit to step back to page one.
When they click Send -- this is the part that I think merits some thinking
-- I've decided to do a sort of poor man's fork. That is, I write the
message body to a temporary file; then I execute myself with an exec()
call with args $to, $subject, $message_filename and redirect any output to
/dev/null; then I say "see ya later" to the browser.
If I'm in CLI mode, I open the message file, to do the db query, loop
through the result sending mail with PEAR::Mail/sendmail, and log some
things along the way, then email a report to the user.
This will be on a shared server. To keep Evil Spammer from getting a hold
of it, I will be in cgi-wrapped mode with execute permissions set to only
me. And the web interface will require authentication of course.
My reasoning is that if it takes a long time to send all those emails, I
don't want the user sitting there waiting and having the ability to hit
reload or otherwise mess up the process once it's under way. My
understanding is that if exec() doesn't produce any output, then PHP does
not hang around and wait for the exec'd process to finish, but rather
continues execution right away, which is exactly what I want.
Make sense?
Thanks,
---
David Mintz
http://davidmintz.org/
"Anybody else got a problem with Webistics?" -- Sopranos 24:17
More information about the talk
mailing list