[Zope] Re: Non-blocking MailHost

[Kapil Thangavelu]

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