[Mailman-Developers] GSOC Project Discussion

[Barry Warsaw]

On May 17, 2013, at 04:58 PM, Richard Wackerbarth wrote:

>Would it be easier if we just treated owners and moderators as a couple of
>additional mailing lists.
>
>In other words, for list XXX at example.com, we also have virtual lists
><XXX(owners)>@example.com and <XXX(moderators)>@example.com Where the list
>names are accessible only from within MM.
>
>Thus a moderator would be subscribed to the <XXX(moderators)> list and that
>subscription handled just as any other subscription would be handled.

This is an interesting question, but let me rephrase it into MM3 terminology
to see what we can coax out.

MM3 has this notion of "rosters", and they are a fundamental object in the
system, as described by the IRoster interface.  Through a roster, you can get
at the IMembers, IUsers, and IAddresses which are contained in the roster.
You can also look up an IMember from a given email address; if it's in the
roster then you get back the matching IMember, otherwise you get None.

Mailing lists point to a bunch of rosters, and this is in fact how the
subscriber information is accessed.  A mailing list will have:

 * an owners roster
 * a moderators roster
 * an administrators roster (all owners + all moderators)
 * a members roster
 * a roster of regular delivery members
 * a roster of digest delivery members
 * a roster of subscribers (all regular + all digest)
 * a roster of "non-members"

So, when we want to send a message of a post held for moderator approval, we
send that message to every IMember in the administrators roster.

Here's where it gets interesting.  Rosters are not modeled as rows in a table,
they are modeled as queries.  This is cool because you can actually compose
rosters, or pull their information from any source, including those external
to the core.

One of the use cases for rosters that I've always had in mind are a better way
to do MM2-style umbrella lists.  Let's say you have one mailing list for all
of your band's New York fans, and another for all of your band's San
Francisco fans.  It should be very easy to compose a parent (i.e. umbrella)
list which had a roster combining the New York and San Francisco rosters, and
it is this roster that you would deliver to when your new tour was starting.

Another use case: say a site is doing maintenance and they want to inform
every subscriber on the system that it will be unavailable for a while.  You
could easily compose a roster that included every registered (and validated)
email to every mailing list, and then you'd send a message to that roster.

I think this same kind of arrangement would work for some of the things that
dlists wants to do, or topics, etc. and I'm sure you can come up with a
zillion other use cases.

So, in this model, what is "a mailing list"?  It's really all the
configuration stuff *around* rosters, such as how you send a message to that
roster from outside the system, what gets stuffed into Subject headers, and
message footers, how do posted messages get transformed on the way to the
roster membership, and who gets to send messages to them.

I think this isn't far from what you're asking in your original question, and
there's much to explore here.  Whether the full power of this can be or should
be exposed to the web ui, or the mail boundary, is much fuzzier in my mind.
But I can clearly see how a determined developer could make this work pretty
easily.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130530/adefd3e4/attachment.pgp>