suggestion for two important (I think) features
Barry,
Recently I started shopping for some web hosting service and obviously was looking for a web hosting service that uses mailman for mailing lists management.
Soon realized that all of these services have installed one instance of Mailman and serve the lists for the various domains using some sort of scripting and the virtual domain functionality in Mailman.
Now, not being able to have control of the Mailman installation, there are two problems related to those who would like to move a list with its archives and listmembers from one hosting service to another.
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.
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.
Any thoughts?
thanks, Mentor
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
participants (2)
-
Barry Warsaw -
Mentor Cana