[Mailman3-dev] Problem with the schema

John-Paul Robinson jpr at uab.edu
Wed Mar 30 18:58:34 CEST 2005

Agreed.  It sounds like a roster is list subscriber namespace construction 
mechanism.  When viewed from the perspective of a specific list, the list 
name is the root of the tree, the rosters are internal nodes, and the 
subscribers are the leaf nodes.  It seems that a list "delete" would 
relate to the deconstruction of this heirarchical relationship and not 
necessarily the destruction of its constituent parts.

Until a roster is orphaned (no longer has any references) it is not
eligable for deletion (similar to a hard link in a traditional file
system).  Note, in cases where the subscribers and rosters come from an
external source, the "zero reference" condition may not be under the
control of mailman.  That is, a roster may always have > 0 reference in
this situation and mailman would never try to delete it. 

An example of what I'm thinking of: I construct a mailing list 
of all students in a department based on the rosters from all offered 
courses in the department.  This data may be external to mailman and 
mailman has no responsiblility for managing it.  I would be interested in 
telling mailman to construct a list named cs-students using rosters for 
cs101, cs201, cs301, etc.


On Wed, 30 Mar 2005, Ian Eiloart wrote:

> --On March 29, 2005 22:33:14 -0500 Barry Warsaw <barry at python.org> wrote:
> > I was working on a method to delete mailing lists and I realized that
> > our schema as currently designed doesn't support it.
> >
> > Think about Rosters.  In order to support composition of mailing lists,
> .
> .
> .
> >
> > Anyway, I'm not sure what we should do, so suggestions are welcome!
> > -Barry
> >
> Hi,
> Sounds to me like you're thinking that a roster is a property of a mailing 
> list. That must be incorrect, it's the situation that you want to get away 
> from.
> At our site, we're likely to have more rosters than mailing lists. If 
> you're using a relational database for this stuff, then the rosters will 
> belong in one table:
> ROSTERS = rostername | userid | etc...
> lists will belong in another:
> LISTS = listname | listdomain | archived | disabled | etc...
> Another table will have ACLs for rosters:
> ACLS = rostername | listname | listdomain | owner | moderator | recipient | 
> poster | etc...
> Now, it may be that you want to have some special rosters that exist ONLY 
> for specific lists. For example, when creating a list FOO in domain BAR, 
> you might want to create a roster FOO at BAR_recipients for the default 
> recipient list. you might also want _owners, _moderators, _poster etc. I'd 
> also want an _exceptions: for people who can't get off a roster like 
> "staff", but want off of a particular list.
> Removing orphan rosters would only be desirable if they belonged to that 
> set of special rosters.
> While I'm here, it would be nice to have pseudo-users for "posters", with 
> wildcards like *@example.com to allow all local users to post to a list.
> This scheme would allow you to delete lists without worrying about losing 
> rosters, but maintain 2.x functionality for those that don't care about 
> rosters. You'd delete a list by deleting it's one entry in the LISTS table, 
> all related entries in the ACLS table, and all the special rosters. You 
> could disable a list by flagging it as disabled, or (better) setting a 
> disabled date in the past. Most admins would want to disable a list for a 
> while before deleting it.

More information about the Mailman3-Dev mailing list