[Mailman3-dev] Flexible data storage

[Ian A B Eiloart]

--On martes, 16 marzo 2004 09:36 -0500 Barry Warsaw <barry at python.org> 
wrote:

> On Tue, 2004-03-16 at 08:38, Ian A B Eiloart wrote:
>
>> I've said before that I'd like to manage internal users (members of the
>> University) differently than external users. If we could eliminate the
>> sending of passwords to internal users (we manager their passwords in
>> LDAP), and also guarantee that external users only had one password in
>> the  database, that would cut the number of reminders drastically.
>
> That's an interesting use case, although I think Mailman itself should
> largely be ignorant of whether they are internal or external users.
>
> 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.

> Take our Students list example.  You might have some grad students who
> were also employees of the university, so they'd be in the employee
> database.  Perhaps you couldn't write password updates to that database
> through the Mailman conduit.  But the GradStudent list would be composed
> of a non-employee roster (which Mailman managed completely) and an
> employee roster (which Mailman imported through a conduit).
>
> -Barry

Er, what's a GradStudent? Is that a current student who already has a 
degree (a post-graduate), or someone who graduated here but isn't a student 
(an alumnus). We don't use the term "grad student" in the UK. Anyway, all 
current students are on our LDAP database, along with the staff. Alumni 
aren't - they'd be an example of an external user.

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.

Then, I'd like to be able to create a list membership with full boolean 
rules. For example, I'd like to have a list lifesci-ug-1 whose membership 
was lifesci-ug AND ug-1 (composed of first year undergraduates in life 
sciences). Or science-ug-1 defined as "(lifesci-ug OR scitech-ug) AND 
ug-1". Or local-ug defined as "ug AND NOT overseas-ug"

Caching these memberships would be useful for performance. A 24 hour cache 
would be acceptable.

Finally, for each list, I'd like the list admin to be able to configure the 
role-based membership, and then maintain a list of additional members 
(perhaps a tutor, technician or an *external* examiner) and a list of 
exceptions (no, I don't know why). I guess the additions and exceptions 
would just be two more rosters, perhaps. So the real rule for, say 
science-ug-1 would be "((lifesci-ug OR scitech-ug) AND ug-1 OR 
my-additions) AND NOT my-exceptions" where my-additions and my-exceptions 
were special rosters for each list.

I guess the default membership rule for a list would be "my-members", a 
synonym for "my-additions".


So, a roster might be the result of an SQL query, or an LDAP query, or a 
list from a flat file or python database. But, it might also be any boolean 
combination of other rosters.



-- 
Ian Eiloart
Servers Team
Sussex University ITS