On 12/6/06, Jon Forrest <[EMAIL PROTECTED]> 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.
> 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. > 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"). > > In reading the Mailman documentation I saw a mention of > an "umbrella list", but the only description here says > "umbrella lists" are depreciated and will be replaced with > a better mechanism for Mailman 3.0". Are umbrella lists > somehow related to what I'm talking about? Umbrella lists deal with lists that distribute their messages primarly to other lists, rather than users. So, no, they aren't really related. -- - Patrick Bogen ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp