[Mailman-Developers] Features requested...

Rick Niess Rick.Niess@usm.edu
Thu, 18 Nov 1999 16:28:47 -0600 (CST)

Hi All,

     Whew!  Sorry for the delay in response.  Been busybusybusy.  And
sick. <snifflesniffle> Getting better tho.  Anyway...

On Mon, 15 Nov 1999, Barry A. Warsaw wrote:
>     RN> subscribe to the list in question, please add another
>     RN> radio-button option for "Conceal yourself from subscriber
> I'd actually like to see more options at the subscription page, if not
> all the options a user can change later (that might be too cluttered
> and daunting though).

     <nod> I'd thought about asking for all of them but didn't want to
push my luck. ;-) Having "as many as is tactful and/or sensible in the
context" would be a good idea, IMHO.

>     RN> 3) Allow the system-wide admin to disable the mail->news and
>     RN> news->mail gatewaying for the whole system and/or for selected
> You can disable news->mail easily by shutting off the cron entry for
> gate_news.  Shutting off mail->news will actually be much easier to
> accomplish with the current CVS snapshot, since you can just edit out
> the ToUsenet module from the message delivery pipeline.

     <nod> I've already done this.  However, it doesn't remove the
configuration option from each list's admin pages.  But I think you knew
what I meant. ;-)

     BTW, from the sound of it, the new modular pipline structure Barry
described sounds like a winner! *lots* more flexibility. Even room for
on-the-fly user modules, etc.  One question, tho.  What was "CVS" mean?

>     RN> 5) Please setup a means by which a user can specify what
>     RN> additional addresses he/she posts from other than their
>     RN> subscription address. (For example, my campus has a mail
> Again, with a real User database, we could easily allow users to
> subscribe multiple addresses, enabling delivery to some or all of
> those addresses, and allowing postings from any of a User's known
> addresses.  Very difficult to do right now unfortunately.

     Yup.  Although I will note that Mailman's current means of dealing
with it (multiple subscriptions, only one actually delivering) is more
elegant than Majordomo's (just multiple subscriptions or a separate list
that doesn't actually handle posts)

>     RN> 6) Please setup a mechanism for a pre-made set of options to
>     RN> be used as defaults when creating new lists.
> which really just means certain list option settings, and then just
> make those settings after the call to newlist.Create().
> A simple hack would be to just have a bunch of classes in the newlist
> script which implement these defaults, and add a command line switch
> to invoke one of those classes on the newly created list.  If you want
> to get fancy, you could publish an API and let folks add their own

     Oy.  OOP has never been my strong suit.  Okay, sticking with the KISS
principle, how about the desired initial "personalities" each be stored in
separate files all stored in a single subdirectory somewhere (ex,
"$prefix/personalities").  The format can be a simple
"maiman_db_variable_name='desired value'" on each line allowing for hashed
comment lines. Look familiar to some Majordomo users? <g> (Note: We'll
have to figure out a way to weed out erroneous input from here.) Then the
site admin can specify that personality with a command-line switch to
newlist.  And this could be handled right after newlist.Create(), as you

     *And*, we could implement a separate switch to import a
Majordomo-style config file and map to the appropriate values, etc.  Not
hard, just tedious.  I'll be happy to sit down and write up a map of what
Majordomo values go to what Mailman values if someone can use this in the
short term...

>     RN> 8) The <body> tag is not currently setup right for error
>     RN> pages.
> I don't understand; I guess you mean the driver script is broken?  Can
> you give me more details?

     Sure.  All the normal admin and default user pages have a BODY tag
like '<BODY BGCOLOR="#ffffff">'.  But most of the erorr pages (ex, from
the archives and options CGI's) only have '<body>'.  Not terrible, just
cosmetic.  Then again, some of the error messages themselves could use a
little elaboration.  And uniformity. (Yes I know it's an opensource
project and, no, I'm not berating anyone.  Just pointing out the obvious
so it can be fixed at some point.)

>     RN>      Lastly, I'd like to note that, while I understand most of
>     RN> what's going on in the code, I don't have time ATM to sit down
>     RN> and really learn Python.  Hence, I don't have the expertise to
> Well Rick, it'll probably take you about a day to learn all the Python
> you need to become a prolific Mailman hacker!  Just be sure to try it
> /before/ you eat the turkey dinner and get all "stuffed". :)

     <giggle> We shall see... ;-) BTW, I should note that I have not
really dealt with OOP before. (That's one of the reasons Python seems so
daunting to me.) So if I've made some statments that don't make sense for
Python, now you know why.  Anyway, thanx for listening.

						~ Rick ~
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------