[Mailman-Developers] Re: being flexible.

[Simone Piunno]

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 
miss something?

> > 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 
web server.

> 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 
better protocol?

> Which would it open to the product that are not current addressed?

sorry?

-- 
Adde parvum parvo magnus acervus erit -- Ovidio