Chris Withers wrote:
Kapil Thangavelu wrote:
i was think about this in regard to doing bulk email, the best i could think of was to response.write and than send the email. no real confirmation but the user gets the page and the mail hopefully gets sent. i was planning on doing this from python with either calls to the mailhost or smtplib.
What we really want is a non-blocking MailHost.
Anyone know how or want to write one?
first, lets gather some requirements... probably best done on a fishbowl wikis... any volunteers?:) what do you mean by non-blocking MailHost, the smtplib.py waits for a reply to see if it should raise an error, but thats it as far as block that i see, i pretty much regard that as nonblocking and proper. if you're looking for send which doesn't check for reply than you could just hack smtplib but i doubt you'd see any performance benefit. assuming that smtplib and Mailhost are nonblocking... then the question becomes how to make it suitable for bulk emails and what are the requirements? do you want a mailhost that isn't connected to via a publishing thread? ie is it a requirement that processing won't affect a zope site and no response will be sent back to zope for messages processed (although an xml-rpc callback is possible). do you want to get respones back for messages you've sent? if this going to be added as a general zope feature its probably best to add some sort of mail queue, that can be added to by other zope objects. this would also avoid the overhead of connecting to the mailserver on every mail send. does it need to be multi=platform? (ie no cron, no popen2) if its for squishdot i guess i can assume the answer to this and my next question are yes. are zope/python solutions preferred? i ask because i've been considering a zope bridge into JServ which has an enterprise capable email system in James (http://java.apache.org/james/) a quick stab at portable implementation outside of zope would bundle a python script to be called by popen2 on Unix or spawnv on Windows that would read a pickle of email data and send it. course its ugly but it would work, could even get fancy and do it with an asyncore. another quick stab, if you assume the existence of xron, you could store email messages to be sent and a list of addrs to which they should be sent and xron it to be sent some other time. one possible (minor) speed improvement depending on the protocol def and the various server implementation is to mantain an open socket to the server as part of the MailHost, or at least maintain for as long as possible before getting a new connection. i need to sleep, i'll brainstorm some more in the morning night Kapil
cheers,
Chris