Hi John,
It really sounds like you really have your mind set on building a fancy pants queue system, but cant really justify it. Frankly, I think you are doing some technical masturbation, want to build something far more complicated than is actually needed, and want to solve problems that don't really exist. At first, you described your problem as having dual codebases, and then it morphed into a performance discussion. Which is it?
Thanks for your reply. Actually, it's the exact opposite. I want to make the system as simple and easy as possible. The problem is that right now, we have our front end code send emails. The developers are starting to get annoyed at writing all of the logic over and over again for each front end (for instance, we're in the middle of writing an iphone app as well, which is a more simpler implementation, but we need some sort of REST layer to facilitate communication with the database). I've been implementing stored procedures and triggers into our database, which removes much of the logic from the developers hands. Creating an account is done the same way, whether you're using our mobile front end, primary website, etc.
The issue we're having is with emails. If all emails were bulk, I'd simply have a cron that ran, processed emails for subscriptions and such, and send them. But, as we've said in this thread, some emails need to be instantaneous. So drawing the line between what is done in the front end code vs. what is done in background processing is what I'm trying to decide. I'm using the terms "active" and "passive" to mean two different things.
The "fancy" queue you speak of is actually my favorite idea right now, as it allows me to generate emails in a number of ways (triggers, stored procedure, a manual INSERT into the table if needed, etc.). If the developers need to do a forgot password email, they can call the forgot password stored procedure, with the user ID, which will generate a hash, generate an email in the queue, send the email, etc. Or, for more batched emails, I have a trigger setup that creates an email in the queue everytime a post or reply is made. The email queue won't be "one row per email" - it will more be "one row per task". The background script will know what to generate based on what's in the queue.
I'm really not doing any "technical masturbation" or any of the sort. Promise. I'm just trying to make the system as flexible as possible. I really don't think it's that complicated.
Thanks for your input! -Matt _______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
