At 11:49 PM -0500 9/7/00, David Champion wrote:
I'll be very interested in anything you come up with.
Basically, I plan on splitting content out from mailman completely on a functional basis, and derive it through an API. The API is basically defined as "GetThing(thing, list, language)", which returns a hunk 'o text.
Now, "thing" is any hunk of text, for instance, "unsubscribe_message" or "listinfo_page". A certain set of these would have to be defined as standard entry points, and can include other things. embedded things are expanded within GetThing, so the mailman program doesn't even need to think about it.
Now, behind the scenes, it can get funky, since many of these things are configurable on a list-specific or global basis, some are meta-things based on system config or state, etc. But conceptually, I want to pull out all of the messaging content from the rest of mailman, because it makes it (a) infinitely easier to administer, change and user, (b) cuts the complexity of the code completely, (c) makes stuffing it in a database for management trivial (and database independent, in theory), and (d) you basically get multi-language support for free (well, in theory) because you can define parallel sets of content in each language, and let the end-user define which their preferred language is.
It needs some fleshing out, but that's the 10,000 foot level. it'd need an administrative interface in the API, and databasing in the back-end, and administrative controls such that the site admin can lock down some values so that a list-administrator can't change them, something not currently possible with Mailman.
-- 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?'"