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

[Brad Knowles]

At 8:59 AM -0800 12/6/06, Dragon wrote:

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

Don't jump to conclusions too quickly.  See my other message first.

-- 
Brad Knowles, <[EMAIL PROTECTED]>

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.
--
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

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

[Brad Knowles]

At 8:26 AM -0800 12/6/06, Jon Forrest wrote:

>  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").

Unfortunately, there are people on this list who won't get that 
reference.  I didn't get it the first few times I heard it.  I had to 
have it explained to me.

For those people, please understand that this is a particularly dry 
form of humor, and the word "small" is used in more a cosmological 
sense -- as in, anything that exists on this planet is necessarily 
small when compared to the size of the entire Universe.

For more information, see  
and .

-- 
Brad Knowles, <[EMAIL PROTECTED]>

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.
--
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

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

[Brad Knowles]

At 10:39 AM -0600 12/6/06, Patrick Bogen wrote:

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

Correct, insofar as it goes.  However, these are command-line tools, 
and one of the things I'd like to see is a move to make it possible 
to do everything that can be done from the web interface, just as 
easily (if not more so) as you can do from the CLI.  But that's a 
very long-term goal.

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

Yeah, that would be a huge rewrite.  Now, Mailman3 will be a complete 
rewrite, and this kind of thing would be a perfectly valid subject to 
discuss on that list.  Of course, no one knows when Mailman3 will 
arrive, so again this is a long-term issue.

-- 
Brad Knowles, <[EMAIL PROTECTED]>

Trend Micro has announced that they will cancel the stop.mail-abuse.org
mail forwarding service as of 15 November 2006.  If you have an old
e-mail account for me at this domain, please make sure you correct that
with the current address.
--
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

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

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Dec 6, 2006, at 11:59 AM, Dragon wrote:

> As far as I can discern from my limited perusing of source code, it
> would be a huge change in architecture.

This is true.  While a more detailed discussion of this topic belongs  
on the developers list, I will say that my plan is to improve the  
situation in MM2.2 by developing a 'styles' feature.  It won't go as  
far as being object oriented with attribute inheritance, but it will  
allow you to group common attributes in a style, and then apply that  
style either when you create the list or after the fact.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRXb/RnEjvBPtnXfVAQJJRgP9HwRZKMM03JxD09jOqT6VWZWJNzGvP0/9
HeflKT45PejNmRI9r9T3+G8K8fRUn5Ih/byKP7pIRdgSlyKlUs9I9abybdB6KE/4
r89ectug8iYWriZksBf/Gwe9MqzQcMXN6sdJBuJgnlnyKgFjQlxUBl/ccHiAOztD
kFbwZTWVDbc=
=Nkl7
-END PGP SIGNATURE-
--
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

Re: [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 <[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.

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)
~~~

--
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

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

[Patrick Bogen]

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

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

[Jon Forrest]

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.

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.

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?

Am I completely out to lunch or does this make any sense?

Cordially,



-- 
Jon Forrest
[EMAIL PROTECTED]
Computer Resources Manager
Civil and Environmental Engineering Dept.
305 Davis Hall
Univ. of Calif., Berkeley
Berkeley, CA 94720-1710
510-642-0904
--
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