[Mailman-Developers] Re: Future of pipermail?

[Chuq Von Rospach]

At 10:53 PM -0800 11/21/00, J C Lawrence wrote:
>  > Authentication is a big bugaboo in general, which Barry and I have
>>  hashed around a bit. More on that someday, maybe.
>
>FWLIW I see authentication visavis Mailman as a two level problem:
>
>   list activities (command confirmations)
>   access control

Okay, I hope Barry doesn't mind, but since the talk has started, 
here's something I sent him a while back that we've sat on to get 2.0 
out the door. But it's a first cut at my idea where some of this 
ought to go... When you see this, you'll start to really understand 
where I'm coming from in this whole API/module thing -- everything in 
the system is a module of some sort, that communicates via an API -- 
which means that in theory, aynone can replace any piece of 
functionality by simply replacing the module. It also means that each 
module can be tracked and developed separately, since all it needs to 
worry about is conforming to the published API.

The trick is going to be architecting the modules, interfaces and 
APIs, and deciding one which ones are central to mailman, which ones 
peripheral and which ones are optional. But when we're done, it 
doesn't matter if you use DB or a filesystem database model, as long 
as the glue inteface exists. And it doesn't matter if you use the 
current mailman subscription interface or download your data from a 
corporate database running Oracle and throw out the entire 
subscription system -- because Mailman no longer cares. So the whole 
archiving issue is a subset of a larger issue, which is defining and 
standardizing all of Mailman and breaking it up into pieces that meld 
into a cohesive whole.



---
Date: Wed, 11 Oct 2000 23:30:28 -0700
Subject: Re: Planning Mailman 2.1

At 12:15 AM -0400 10/12/00, Barry A. Warsaw wrote:
>
>     CVR> Actually, I want to talk to you about this -- I have an idea
>     CVR> that you'll love, or hate, and no middle ground. It'd be a
>     CVR> "mailman 3.0" thing, and it'll turn it on its ear. But the
>     CVR> possibilities are stupendous. I just haven't brought it up
>     CVR> because I know you've been busy.
>
>(barry's comments deleted...)

Okay, here's the other rock.

What I want to propose is a new major project -- an open, extensible 
membership database system. This would completely replace the 
existing mailman subscriber system.

Here's what it is -- it's a web-based (and, perhaps, optional e-mail) 
interface to a member database. That database would manage and 
authenticate members for a given environment (site, subset of a site, 
whatever we plug into it). Front end is web. Back end is DBI, and I'd 
want to do initial support with MySQL, but in theory, want to allow 
it to use and DBI-compatbile system).

So far, no biggie. But here's where it gets different.

The membership database system uses a plug-in architecture of some 
sort and defined APIs to allow you to write an access module for 
anything that needs a membership database. That will allow you to 
define a tab on the membership page to manage whatever it is you need 
managed, by using the common pool of data (user name, email addr, 
etc, etc), plus keeping custom data for each module.

End result, you go to a membership page, register, and once 
registered, can access any system configured in -- whether it's 
mailman, user forums, a personal home page, web logs, whatever. For 
the user, there's a single consistent interface, single account, 
single password, and no confusion. for the project (like mailman), it 
lets the membership database worry about that stuff and focus on 
doing what it does best -- delivering mail.

I've come up with this while trying to put together a multi-system 
community setup. lists, web boards, archives, real time stuff. And 
doing research into communities about other things people might want, 
whether it's public member directory pages, archive access controls, 
even things like a community calendar. Trying to integrate everything 
is, um, a bitch. Everyone wants to control their own data, when lots 
of that data is in common.

So, I thought, build a centralized system for managing that common 
data, and allow it to be customized by compatible systems that 
interface to it. for mailman, you rip out all of the user and admin 
stuff, and instead write an access module that defines what mailman 
needs for subscriptions, how to query mailman for info (like what 
lists to manage), and how to get subscriber lists so you can deliver 
to them. A second module handles defining admin access, because if we 
do this right, those are simply tabs on the member pages as well.

It's conceptually very simple -- but implementing it's going to get 
gnarly. it's something that will require a lot of architecting 
(basically, we're going to need an interface like Apache's DSO), and 
to do ti right, we'll have to define a number of services to 
implement with it to make sure the API works. MLM is one, public 
member directories is another, and web forums is an obvious third 
(whether we evangelize some technology in or go try to build one 
we'll have to see). Oh, and it needs to be language independent, 
although it would be written in Python.

Sound interesting? kinda like a membership ZOPE.

I think simply the idea of a system that allows people to stop 
building yet-another-member-database is a big win, but if we can 
start integrating stuff as well, it gives sites real opportunity for 
synergies down the road.

It needs a lot of fleshing out, and it's not a short term project, 
which is why I think it's something to do parallel with the Mailman 3 
timeframe. It's something I'm more than happy to spearhead and 
architect, but at the same time, it needs some serious partners and 
backing. It's something that if you toss it onto freshmeat and wait 
for people to find it, it'll die. But if we can find a few key 
technologies to work with it and make it happen and support it, could 
really go places.
-- 
Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com)
Apple Mail List Gnome (mailto:chuq@apple.com)

The vet said it was behavioral, but I prefer to think of it as genetic.
It cuts down on the liability -- Get Fuzzy