[Mailman-Developers] Requirements for a new archiver

[Barry Warsaw]

On Mon, 2003-10-27 at 16:44, Iain Bapty wrote:

> Twisted eh? I will have to look into that.

Indeed.  I'm using it in my Mailman3 experiments, and I think while
Twisted is a big package, it gives us a lot of bang for the buck.

> >Also, I really want the next generation archiver to do everything
> >through cgi (or equivalent programmatic interface).  The ability to
> >massage the messages on the way out to me outweighs the benefits of
> >vending messages directly from the file system.
> >
> This is where my ignorance shines, could you elaborate a bit on this 
> part please? By this, do you mean you want all queries to be setup and 
> executed by a user through the web interface? Why can't messages be 
> massaged from the file system?

In MM2 we made the conscious decision that public archives should be
vended from the file system.  That's why when you read the archives of
this list through http://mail.python.org/pipermail/mailman-developers,
an Alias directive maps that directly to a file on the file system.  We
were primarily concerned with the overhead of firing up a Python
interpreter, extra processes, etc. for every archive hit.  Note that
private archives go through a cgi so they can enforce access rules.  I
think this was the right decision for the time.

Chuq made some convincing arguments that even public archive access
should go through a script.  By generating the viewed archive message on
the fly, from its native source, we'd have all kinds of control over the
presentation.  Such as: changing the address obfuscation rules on the
fly, the ability to retract or re-publish archive messages on the fly,
more advanced threading options, no artificial date divisions, the
ability to change the look and feel easily, etc.  With proper caching
machinery and the use of more modern programmatic fulfillment of web
requests (e.g. mod_python, twisted, etc.), this should be efficient
enough.

-Barry