On Jan 16, 2018, at 02:51, Colin Watson <cjwatson@ubuntu.com> wrote:
I possibly should have explained our situation in a little more detail. The way we have things set up with Mailman 2.1 is that any team in Launchpad (teams are basically just a collection of people, with varying policies on who can join them etc.) can have a mailing list if its administrators want one, and they enable it in the Launchpad web UI. If you want to subscribe to one of these lists, you join the team in question and you press the "Subscribe to mailing list" button.
Oh yeah, that was another thing that Launchpad inspired: the whole preferred email address thing. Thinking about it again now, I’m actually still kind of amazed that we could fake a one-unified-account-per-user facade over Mailman 2.1’s each-list-is-a-silo view of the world. At least you won’t have *that* mess to worry about any more. :)
I'd been thinking more of a new enum in HyperKitty for the visibility state, since it does seem like quite an archiver-specific thing.
Yep, I think that’s probably the way to do it. Then the question is who and how is HK informed about these state changes?
Well, IArchiver.archive_message sends a message from core to the archiver. I'd been thinking of something like IArchiver.set_list_visibility(mlist, visibility) which would send a message from core to the archiver to instruct it to show/hide the archives. It doesn't seem too out of line, though I'm not wedded to it either.
I don’t think that’s the right way to do it, because as Steve points out, IArchiver is really a half-duplex interface. It’s there solely to abstract away the different mechanisms for getting messages from MM3 to the archivers of choice. Even the API for getting a permalink is generally not supposed to function by direct 2-way communication with the archiver, although if an implementation of IArchiver wanted to do that, we can’t stop it.
I suppose that one alternative could be that we handle this in a Launchpad-specific add-on to HyperKitty, since at a minimum we'll need some of our own code there to deal with sign-in for private lists. So the same bit of custom code that determines whether a list's archives are private could hide them from everyone except their owner, or even deny their existence entirely. It sounds like maybe we'd be better off pursuing that?
Yes, I think so. The other way seems too round about; you’d make a REST call from LP to Core, then Core would call a method in an interface whose implementation then sends a message to HK. Having LP talk directly to HK is much more straightforward, and also gives you the ability to have HK respond with various states or information as needed. The other way, there’d be no good way to get information back up from HK to LP.
Hope that helps, and best of luck! I think it would be a fun project… if I was retired or it was 5 years ago. :) Please do come back with any further questions.
-Barry