[Mailman-Developers] Re: suggestion for two important (I think) features

[Barry Warsaw]

On Sat, 2003-04-05 at 10:49, Mentor Cana wrote:

> 1. Without admin help a listowner can't move the archives of a list from
>    one hosting service to another. This can be resolved by providing an
>    "Upload old archive" option/button under "Archiving Options" and after
>    the 'old' archive is uploaded successfully, the bin/arch command is run
>    for that list. We already have the capability to download full archives,
>    i.e. the *.mbox raw file.
>    In addition, this removes some work from the Mailman admin and into the
>    hands of the listowners.

Several things frighten me about this: 
- What do you do about huge archive files? 
- bin/arch is extremely memory unfriendly
- concurrency on the list and the archive while the update is occurring

We could impose upload limits to address the first two, although I'm not
sure what good defaults would be, and it adds another layer of
complexity to the scenario.  The list admin would be forced to split up
their archives and submit each independently (tedious, plus the
concurrency issue raises its ugly head again).  Or you'd have to fall
back to admin help anyway.

> 2. Also, without the help of the Mailman admin, a listowner can't get the
>    full list of listmembers. A button "E-mail me the raw list of
>    listmembers" can run the "bin/list_members" for the list and e-mail it
>    to the list admin from the list's configuration.

Why doesn't an email to listname-request with the subject "who adminpw"
do the trick? :)  Okay, maybe the format isn't perfect, but have I told
you about my idea of hooking Mailman up to Twisted so you could have
XMLRPC access to your list databases almost for free? :)  I'm seriously
thinking about this because you'd potentially gain other benefits: the
default out-of-the-box implementation probably wouldn't need a web
server or an mta, and we /might/ be able to get rid of the multiple
processes (but I'm not sure about that).

-Barry