[Mailman3-dev] Problem with the schema
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
> 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
> 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