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.
<snip> > which really just means certain list option settings, and then just > make those settings after the call to newlist.Create(). <snip> > 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 <snip>
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 said.
*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!" ) / email@example.com --\ )------------------(_/-------------------------------