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@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:
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.