[Mailman-Developers] some more futures on mailman...

Chuq Von Rospach chuqui@plaidworks.com
Fri, 15 Sep 2000 21:38:00 -0700


At 1:15 PM -0600 9/15/00, Sean Reifschneider wrote:
>On Thu, Sep 14, 2000 at 12:13:02PM -0700, Chuq Von Rospach wrote:
>>Yah. That one gets really interesting, really fast. There are all
>>sorts of wrinkles here, because even with sendmail, you start having
>>to tweak all sorts of files and keep them in coordination, and that
>
>I think that's beyond the scope of Mailman...

Right now, yes. Inherently, there's no reason why it can't be handled.

>  >If you are on such a host, how do you get to the right pages if they
>>overload on top of each other in the namespace? ugh.
>
>Are you talking about if they're using name-based virtual hosting, or ???
>If you are running Mailman under a broken web server,

I'm talking about using name-based vhosting, and clients that don't 
deal with the HOST: support cleanly, or which come in via IP 
addressing.

>I wouldn't expect
>Mailman to do anything meaningful.  ;-)

But it can, so why not?

>Crippling people who ARE using
>functional web servers

problem is, I'm not talking about broken servers, but client-side 
issues that aren't under the control of the site admin, but which 
have to be dealt with.

>  >At some point, you almost have ot start running multiple instances of
>
>Why?  There's a difference between installing multiple binaries, and
>having a single set of binaries being able to access multiple sets of
>data.  The latter is not evil.  ;-)

That latter is not evil if you're running three or four or five sets 
of data. But, oh, 200?

>Maybe not to you, but IMHO there is good reason to have it in Mailman.

agreed. I just don't see it as a high priority.


>Yeah, like a search path.  ;-)  Why are you mapping the concept
>"searching a list of locations" onto the OOP domain?

because it buys you a lot of stuff that goes with this. For instance, 
international support, since you can build languages and language 
preferences into the hierarchy. Also, administrative flexibility and 
authentication, since it gives you much ability to define which level 
of admin has permission to change what fields. Monolithic control 
isn't useful in larger sites, because the site admin ends up getting 
nibbled to death by the ducks.

>How are you defining the objects based on other objects?  Are you saying
>that the host "unsub message" would be a concatenation of the
>distribution and site messages?

I'm saying you define a suite of objects, plus the ability to define 
custom objects if you want, and you resolve them through the 
hierarchy. So an unsub message would likely be defined as a header, 
some unsub text, and a footer. And the unsub text will be some ascii 
text with embedded objects that resolve to information, and those 
objects might refere to other objects, and...

so when you end up, you have the full, customized text of the unsub 
message with the appropriate user information, but you do it by 
defining things and plugging them in through the hierarchy 
recursively. Very simple, very powerful. Exceptionalyl flexible.

>Presumably, if you read a "list unsub message" it may search back up
>the heirarchy searching for that message, but if you write it it would
>write directly to the list context, not search upwards.

Basically, yes. you ask for this "list unsub message" thing, and it 
goes and finds the definition of what that is, and recursively tracks 
down and fills in all of the embedded objects until none fo them are 
left -- whether those items are defined at the list level (like the 
list name), but user level (the user address) or the site level (the 
host name). Think of a big mail-merge system on steroids, and you get 
the basic drift.


-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

And they sit at the bar and put bread in my jar
and say 'Man, what are you doing here?'"