[Mailman-Developers] Re: being flexible.
pioppo at ferrara.linux.it
Fri Oct 31 16:04:50 EST 2003
On Friday 31 October 2003 20:17, J C Lawrence wrote:
> Right, but the information lost across the non-SMTP translation is
> irretrievable and necessary.
sorry, I don't get it.
Right now we're receiving messages over a pipe and as far as I see we're not
using any environment or command line parameter (beside the script name) so
where's this SMTP magic?
Fetchmail would pass exactly the same bytestream over the same pipe, or do I
> > We all know CGI is sub-optimal. We're also planning to stop vending
> > archives directly from disk, increasing the CGI load.
> True, however the processing delta can be kept quite small.
This is not only a CPU load problem... this is also a lock contention (over
the list configuration) problem.
> > mod_python or a web runner would perform better.
> The problem there is that they are insufficiently portable.
I already explained how this can be solved for a web runner, please argument
on that proposal.
> > I feel the reverse-proxy configuration (similar to zope) would be the
> > better choice.
> Why would it be better?
first of all we absolutely need to avoid the CGI to load, modify and save the
list config. There's a big lock contention and it's a PITA to code.
This would be true even for a transactional berkeley DB or similar setup.
Remember that we want to configure and administer TTW also the spam filter.
Right now in a 200 subscribers list I have:
[pioppo at liston flug]$ ll *.pck
-rw-rw---- 1 mailman mailman 56639 Oct 31 19:59 config.pck
-rw-r--r-- 1 mailman mailman 378634 Oct 31 19:59 spam.pck
Can we afford to re-load such a beast for each HTTP request on a list with one
million users and/or some megabytes of spam data?
Then we get a cleaner code (we won't have m.Load() and m.Save() scattered all
over the map)
Finally, we completely avoid the SGID driver.
> What are the disadvantages of those benefits?
I see none.
> What specifically useful or necessary function would it add which is not
> being served today?
we'll be able to centralize the configuration data all in one place (instead
of one .pck per list, which we're pretty much forced now due to the CGI
reload .pck everytime).
This is good:
- to move toward a user-centric Mailman
- to easy system administration (backups, etc.)
- to build a site-admin web panel
Furthermore, Mailman could run on a different machine, not the one running the
> What interesting and valuable deployment cases
> would it prevent or make more difficult?
On a web server without support for reverse proxy rules, one will need to
configure and activate the glue CGI. It shouldn't be more difficult than it
is now (we already have a glue CGI).
I know, this CGI could talk with the running Mailman using something different
from HTTP, so we could do everything I described without a built-in HTTP
server. We could use a some-different-protocol server, but do you know a
> Which would it open to the product that are not current addressed?
Adde parvum parvo magnus acervus erit -- Ovidio
More information about the Mailman-Developers