Re: [Mailman-Developers] some more futures on mailman...
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... Besides, if your MTA doesn't do these things well, you haven't really lost anything, you're just back where you are now (except maybe you want to upgrade to a bit more modern of an MTA ;-). I'm sure that other MTAs handle it well, but I know that QMail does.
Basicly, e-mail for "list@lists.domain.com" on my box gets forwarded the local user "mailman-lists.domain.com-list". I have a "default" processing program set up for the mailman user which strips out the domain name and destination, and sends it to the correct program with the correct arguments. At the moment it simply ignores the domain portion.
ignores the database backend details within mailman -- and how do you resolve issues where the vhosting fails (for instance, not all web
Again, I think that's beyond the scope of what we expect Mailman to handle. Garbage in, garbage out... If the web server doesn't pass the URL to the CGI, or uses an unknown domain, I'd expect mailman to treat it as if it does now -- listing all domains/lists for the admin page, and none on the listinfo page if the "show only this domain" option is set...
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 wouldn't expect Mailman to do anything meaningful. ;-) Crippling people who ARE using functional web servers (I mean, Apache is well over half the "market", right?) just because somone might have a broken server doesn't help anyone... I don't see my changes as HINDERING people who use broken servers, they just couldn't do the extra domain-based functionality. They'd probably HAVE to set it so that all domains lists were shown on listinfo and the like.
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. ;-)
mailman. You take the basic problem of trying to have "chuqui@plaidworks.com" and "chuqui@chuqui.com" going to different people on the same machine -- and throw gasoline on the problem.
As I said, with QMail at least it's not really an issue. The mail goes to "mailman-plaidworks.com-chuqui" and "mailman-chuqui.com-chuqui", which my delivery program would then be able to handle to the list processing program with the arguments "plaidworks.com" and "chuqui". In sendmail you'd have to do more work to set up the individual accounts, but it shoudl be doable there as well:
chuqui@plaidworks.com: |/home/mailman/bin/whatever chuqui plaidworks.com
Me -- I handle it by not allowing it. I *could* figure out a way, but it just plain old isn't worth the hassle.
Maybe not to you, but IMHO there is good reason to have it in Mailman. I don't run into it being a problem right now, but as I add more domains it's likely to be. As we're hosting the lists for free as a community service, nobody is likely to complain, but it's still worth doing IMHO.
What we're talking about (and need) instead is a hierarchic inheritance system. you send off a request for "the unsubscribe message", and mailman goes off and finds it. Starting at the most specific place in the hierarchy and working down to distribution definitions, it returns the first one it finds.
Yeah, like a search path. ;-) Why are you mapping the concept "searching a list of locations" onto the OOP domain?
The hierarchy would look something like: user->list->host->site->distribution. And the trick is to define each object (like 'unsubscribe message') in terms of other objects, and customize each object at whatever level in the hierarchy is appropriate. That way, list-specific stuff lives iwth the list, not the host. and the two can be changed independently, or list stuff can override host stuff.
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?
defining what objects you need and what the hierarchy is, and also who the owner is -- because there are going to objects that CAN'T be overridden higher in the hierarchy, or that an site-owner will want to tie down and not let a host owner or list owner override.
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.
Sean
[...] who asked "Why do we do it, this science?" No one had an answer until I stood up and said "Isn't there money in a Nobel?" -- Steve Martin Sean Reifschneider, Inimitably Superfluous jafo@tummy.com tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
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?'"
participants (2)
-
Chuq Von Rospach -
Sean Reifschneider