[Mailman-Users] Suggestion For Better Way of Doing List Configuration

[Dragon]

Patrick Bogen sent the message below at 08:39 12/6/2006:
>On 12/6/06, Jon Forrest <forrest at ce.berkeley.edu> wrote:
> > I'm relatively new to Mailman but I've managed
> > to build it from source and set up a few lists,
> > with generous help from this list.
> >
> > While working through issues relating to
> > creating a standard list configuration, I started
> > to feel that there was a fundamental flaw in the
> > way Mailman lists are configured that I couldn't quite put
> > my finger on. Of course, this could be due me not knowing
> > or understanding something, and, if so, I'll be happy
> > to retract what I'm going to say below.
> >
> > Yesterday, I realized that I had made a mistake in
> > how I had configured all my lists (I only have about
> > 6 so far, so this is no great tragedy). This was entirely
> > my fault, and not due to anything amiss in Mailman.
> > So, using the web interface, I fixed the mistake on
> > all 6 lists. This wasn't too bad, but it got me to
> > thinking what I would have had to do if I had 1,000
> > lists.
>The command-line config_list and/or with_list tools have a slightly
>higher up-front cost (in terms of work required), but trivialize the
>cost-per-list for config updates, for the purpose of applying a single
>value across multiple lists.

Pretty much true if you understand Python and this tool. It's pretty 
daunting if you do not. It sure would be nice to have some tools that 
don't require knowledge of how Python works to achieve a lot of 
common administrative tasks.

It would also be very nice to have a full templating system to allow 
customizing all web pages and e-mail notifications. (Just one of the 
things I would really like to see, I don't have the Python skills to 
do it myself but I would be willing to help test it...)


> > All of a sudden the thought hit me that would it
> > be better if Mailman lists were designed kind of like
> > classes in an object oriented programming language.
> > There would be one super list which would be configured
> > with all the standard values you want every list to have.
> > Then, there would be lists derived from the super list,
> > which would only need to be configured to have values
> > different than the super list. There could even be lists
> > derived from these lists, and so on down the line.
>Someone else can probably give a better analysis, but from my
>understanding, something like what you're suggesting would represent a
>significant departure from the current Mailman architecture, and this
>would constitute a fairly major rewrite.

As far as I can discern from my limited perusing of source code, it 
would be a huge change in architecture. This would probably mean 
throwing out what exists now and restarting from scratch. I believe 
that it has been a stated goal to move list configuration to a "real" 
database system in future so this may well become a moot point 
if/when that happens.

To be honest this is also probably a better topic of discussion for 
the developers list instead of for this list.


> > With this design philosophy it would be very easy to
> > make changes that effect multiple lists because the
> > change would only have to be made in one place. I haven't
> > thought it through but it might even be possible for this
> > class-like design to include list membership making
> > it easier to have one list contain other lists as members.
> >
> > Given that Mailman is written in Python, my naive impression
> > would be that this should be relatively easy to implement.
> > (As my old boss Mike Stonebraker used to say, it's just
> > "a simple matter of software").

Your old boss obviously has no realistic grasp of the subject.



Dragon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Venimus, Saltavimus, Bibimus (et naribus canium capti sumus)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~