[Mailman-Developers] Adding headers to mailman generated mails

[Barry Warsaw]

On Thu, 2004-01-22 at 19:31, Brad Knowles wrote:
> At 6:56 PM -0500 2004/01/22, Barry Warsaw wrote:
> 
> >  I had been thinking along the lines of the language for specifying the
> >  data source as a db connection and a SQL command.
> 
> 	We were working on a method to send a specially MIME-formatted 
> message to identify the various potential bodyparts, a list of 
> recipients and who gets which bodyparts, then a language for 
> specifying the template which pulls in the appropriate bodyparts for 
> the appropriate recipients (and ways to insert bits of information 
> about the user themselves into the message).

Did you publish any of this?  I'd like to read it.

> 	I think there are other areas in which I would be inclined to 
> focus my attentions within Mailman, at least as far as efficiency is 
> concerned.  Instead of using pickles, try Berkeley db b-trees, and 
> use that as your "queue" to be processed.  The reason here is that 
> b-trees are designed for lightning-fast cursor access, and all you 
> need to do is make sure it's indexed on certain key fields.  Let 
> Berkeley db take care of the reliability issues (what happens if 
> there's a crash), efficiently caching information in memory for 
> maximum performance, etc....

Mailman 3 will definitely be database backed, via an interface that
allows different back-ends to be pluggable.  My prototypes use
BerkeleyDB through Python 2.3's standard bsddb module.

However, my experience with transactional BerkeleyDB's performance
doesn't make me confident about using it for the queue runner
subsystem.  We'll very likely stick with the file-based qrunner
architecture, although I've worked out a way to use only one file per
message.

> >  I'm not even touching the 3rd rail of putting the MTA /in/ Mailman any
> >  more :).
> 
> 	That solution is called L-Soft Listserv, with LSMTP.  In fact, 
> you're talking about some of the same sorts of things that they do, 
> only you don't want to own both pieces of code that are implementing 
> the desired standard, which will make solving the problem orders of 
> magnitude more difficult.

I know that rail is shiny, but I'm not touching it. :)

-Barry