[Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

OK. Then a "roster" represents the distribution list for a "feed" of outgoing messages.
The "mailinglist" represents the reception point(s) for the incoming messages and the directives for handling the processing of those messages.

The thing that hasn't been addressed is how an individual recipient can affect the processing of messages that are processed while he is a member of a roster.

In particular, how do the "user settings" come into play?  Presumedly, a user can have different settings for each list to which he is subscribed.

What, if any, individual settings apply to moderator feeds? Are these different from those which apply to the feed that the individual receives as a member of the list?

On May 30, 2013, at 6:07 PM, Barry Warsaw <barry at list.org> wrote:

> 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