Re: [Mailman-Developers] Re: Future of pipermail?
On Tue, 21 Nov 2000 18:46:33 -0800 Chuq Von Rospach chuqui@plaidworks.com wrote:
At 4:29 PM -0800 11/21/00, J C Lawrence wrote:
For me WebDAV raises concerns centering around authentication and access security.
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
The former can be handled with ad hod dynamically generated tokens much as subscribe confirms are handled now. I've posted some notes on good implementations on this previously (I liked the bit about auto-genning an URL that did the command confirmation). The latter just needs to be abstracted to a small script which accepts two command line parameters: UserID and Password. The user can then replace that script with anything he pleases, thus authenticating agsinst he pleases be it SQL, LDAP, or lunar weather sensors.
Ditto BTW holds tru for handling membership lists: just have a tool which when run returns the list of members. Simple command line options then spec returning account details, configs, etc. A little over head for text parsing, but not a whole lot (ObNote XML is a reasonable communications format). Simple, easy to extrapolate, nice efficient piped IO, etc.
-- J C Lawrence claw@kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--
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
Yum.
This would have saved us weeksandweeksandweeks of development on the system we built that had Mailman as a critical component.
Anything that is *using* Mailman as just-another-moving-part-among-many faces the memebership management problem and it is nasty,nasty,nasty.
b.bum
Chuq Von Rospach wrote:
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
.... system description deleted ....
At 2:26 AM -0500 11/22/00, Bill Bumgarner wrote:
This would have saved us weeksandweeksandweeks of development on the system we built that had Mailman as a critical component.
Anything that is *using* Mailman as just-another-moving-part-among-many faces the memebership management problem and it is nasty,nasty,nasty.
If we end up doing the authentication widget, I want it to ship with a set of modules and/or interfaces. That would include one that does personal home pages, surveys, an interface to mailman, an interface to a web forum, an LDAP interface of some sort for external directory lookup and authentication purposes, and a few other toys.
With it and a few key tools, you can easily do 90% of Yahoo, minus the big muther sets of data, but when it's done, you're very close to a yahoo portal with clubs, IRC, egroups and some other tools all rolled into a single cohesive beast -- and it'll scale, and it will be extensible through a standard interface.
Assuming, of course, what I want to do works and I don't botch the architecture...
(and what I find scary is I don't see *anything* that is technically a huge stretch. it's all engineering, not magic...
-- 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
participants (3)
-
Bill Bumgarner
-
Chuq Von Rospach
-
J C Lawrence