[TurboGears] Re: TurboMail 1.0 released!

[Matthew Bevan]

Thanks for the feedback, Ksenia! I'll reply to each item in turn: Thank you for releasing the application! The standard mail library would be a great addition to TG. I was actually quite curious why there wasn't even simple e-mail sending in TurboGears.  I think my package would be too much overkill for the average application, though.  It's nice, but the memory and processor requirements of multithreading isn't what everyone will be looking for. 1. Question: with one SMTP connection per thread, can it handle large email volumes? I successfully sent 100+ messages in a few seconds.  If you are sending larger batches, reducing the mail.interval to 5, setting mail.threads and mail.jobs to the maximum your SMTP server will support, and increasing the mail.timeout to a few minutes will help send a lot more, a lot faster.  Note that most SMTP servers do not actually complain when a single connection is sending too much mail - mine accepts the message and immediately deletes it, accepting a maximum of 10 messages. there should be charset parameter available for specifying different text encoding. (as a sidenote,  when it's utf-8, python email library will *always* transfer-encode it as base64. Very annoying) I agree, it's a good option.  The syntax will likely follow kid's configuration directives for assume-encoding and encoding. python email library doesnt care about line length. When using transfer-encoding other than base64, TurboMail should  check that the line length doesnt exceed 998 characters (RFC 2822). (Some mail servers just chop it off :D)  Format flowed library is handy for this (and of course for format-flowed part :) : http://www.zopatista.com/projects/formatflowed The main idea behind the TurboMail library was zero external dependancies, although that library does look awfully nice.  ;)  I'll investigate optional integration of it in the next (1.1) version. mail headers doesnt have to be ascii-only, the reason to use Header module: http://docs.python.org/lib/module-email.header.html Hmm... I'll have to investigate the use of Header and Message classes instead of using MIMEMultipart directly. I think "embed" method of Message class should also check if the file already embedded and/or if the name is already in use You can, in theory, embed multiple attachments with the same name.  It's not a good idea, but you can do it. the outer part of TurboMail message is always "related". I believe it should be "alternative" when plain text alternative is available: 0. multipart / alternative 0.1. text / plain 0.2. multipart / related 0.2.1. text / html 0.2.2. attachment 1 0.2.3. attachment 2 There are four scenarios: Plain text only.  Plain text w/ attachments.  Plain and rich text.  Plain and rich text w/ attachments.  I'll have to make the generator a little more friendly in this respect, then.  ;^) I think TurboMail should take care of creating plain text alternative for html messages. There are several tools that can do it: http://userpage.fu-berlin.de/~mbayer/tools/html2text.html http://www.aaronsw.com/2002/html2text/ http://www.zope.org/Members/chrisw/StripOGram It'd be even easier than that with a simple regular _expression_ that removes brackets and everything between them, in a similar style to how KID templates are rendered in plain text.  (Note that the TemplateMessage class does automatically provide the plain text alternative in this way.) Again, thanks for the input! Matthew Bevan, Systems Administrator Top Floor Computer Systems Ltd. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---