[Mailman3-dev] Flexible data storage

[Barry Warsaw]

On Tue, 2004-03-16 at 11:12, Ian A B Eiloart wrote:

> > The way I've been thinking about it ties back to the roster notion.
> > Rosters may be tied via conduits to a back-end storage, and each storage
> > would have its own policies for reading and writing.
> 
> Well, if a roster is a membership list which can be included in another 
> membership list, then that's OK.
> 
> I need to have rosters with heterogeneous membership though. Some members 
> from one conduit, and others from another.
> 
> And, I want mailman to be able to tie "sussex.ac.uk" email addresses to a 
> particular conduit. My read only LDAP conduit as it happens. I don't want 
> people in that domain (or susx.ac.uk) to be able to register through 
> another conduit.
> 
> Further, I want some lists to be tied to a specific conduit. I don't want 
> people subcribing to "staff at sussex.ac.uk" unless they have a sussex email 
> address.

We've changed our thinking about this stuff post-sprint.  Currently
we're thinking that any magic tying of members to backends happens in
the implementation of the IUserStorage interface.  To Mailman, there's
one place to get and add users and the implementation handles any
necessary magic.  I think that's the only way to maintain our sanity.

One bone to throw at this is that the interface for creating new users
is passed a 'domain' argument that a backend could use to select where
to store the new user data.  The domain will likely be the internal tag
for a virtual domain (e.g. for a web request coming to mail.python.org
or an email to python.org, the tag would be 'python' -- but this is
completely configurable by the site admin).

The implementation should be able to raise a CantCreateUserError or some
such if the backend is adapting to a read-only storage.

> Regarding rosters: I'd like to be able to fetch rosters with SQL queries 
> from a separate database. So, I want to populate lists from ORACLE, but 
> then get email addresses for each list member from LDAP, and when users log 
> in, I want to authenticate against the LDAP database.

I think this is a valid use case and we're going to have to see if the
interfaces we're currently defining will allow you to do this kind of
thing.  I'm going to have a lot of friction against exposing anything
like SQL external into the application (i.e. above the set of
interfaces).

-Barry