On Jan 14, 2018, at 09:45, Colin Watson <cjwatson@ubuntu.com> wrote:
I'm experimenting with a port of Launchpad's mailing list infrastructure to Mailman 3. If Barry's reading, he may remember that this is no trivial task, so I'm very definitely not promising that it will be done any time soon. :-)
For those of you not up on your history, this is interesting for several reasons. I was originally hired by Canonical 11 years ago to integrate Mailman with Launchpad. At the time Launchpad was not free software, so a lot of the design of the integration had to work within those constraints (LP was released under the AGPL in 2009 IIRC). At the time it was painful, especially because it had to keep two completely databases in sync in both directions — not an easy task! Add to that the fact that Mailman 2.1 doesn’t really have a database, just a bunch of pickle files. :)
I’m proud that the mailing list feature of Launchpad eventually became pretty darn solid, with much credit to Colin, Curtis Hovey, and many of my other wonderful former colleagues on the Launchpad team and at Canonical.
This experience also heavily influenced my thinking about the design for Mailman 3, and led directly to the REST-based API. Launchpad has a REST API, spearheaded by Leonard Richardson, who literally wrote the O’Reilly books on web services. And while there were some compromised on “pure” REST in Launchpad, the discussions we had at that time committed my thinking to as pure an approach as I was capable of doing.
However, for the most part it looks relatively tractable with the aid of the plugin improvements in Mailman 3.2.0; I have the rough outline of a plugin that implements much the same feature set as our current pile of monkey-patches against Mailman 2.1 in a much nicer way.
Very cool!
You’ve provided some clarification in a follow up, and I’ll respond there. Apologies for being a little disjointed.
One of the things that may really help you, but which doesn’t exist in a fully baked way in Core is the ability to set web hooks for various events. Core does have an event notification system (via zope.events) and that’s used to inform other parts of the Core about things like subscriptions/unsubscriptions, etc. Where web hooks would be useful is if some event in Core needs to inform Launchpad of that event. However, it’s possible that this falls under the plugins you’ve thought about - and while not general purpose, I’m positive you could do the same kind of MM3->LP notifications that you might find necessary, in custom plugins.
Ideally, I'd like mailing lists to have a "deactivated" state in addition to full deletion. In this state, the list would appear nonexistent for most purposes: incoming email would be rejected,
I forget whether LP uses Exim or Postfix. At least for the latter, it would be fairly easy (if involving a database migration) to include an “active” or “enabled” flag which would be consulted when regenerating the Postfix transport files. I would add this to the MailingList model and make it available through the REST API. Then the LP team admin can toggle this on and off as desired.
I also wouldn’t use the IArchiver interface for disabling HyperKitty access to the archives, but I’ll respond in more detail in the next follow up.
Postorius would deny its existence, etc.
You’ve clarified that Postorius isn’t needed for Launchpad, since it provides what effectively takes it places in the simplified administration u/i.
Cheers, -Barry