On Sat, 2003-04-05 at 10:49, Mentor Cana wrote:
- 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.
- 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