Mailman 3: dlist integration

I suspect the person to answer this is Barry, but I'm sending to the developers list just in case.
I'm working through getting dynamic sublists (dlists) integrated into
Mailman 3 (probably targeting the 3.1 release) and I've got a question:
where should the thread name be stored? Does that go with the message?
Does it need to go in a separate table with message+list as keys?
Some background:
Dynamic sublists is an Mailman 2.1 extension that systers uses so that mailing list subscribers can subscribe or unsubscribe to individual conversations on a mailing list. It's sort of like a fancier, more automated version of topics, where users can start new conversations at will by sending to mailinglist+new@example.com. This is in contrast to topics, which need to be set up by the admin in advance. It's a pretty neat feature and one they've been using for quite a long time, so it's well-tested and because "I wish I could unsubscribe from this stupid thread" is a pretty common requested feature, I'm hoping we can use dynamic sublists to replace topics in Mailman 3.
In a dlist-enabled list, every message is part of a thread, as determined by the posting address used (mailinglist+threadname@example.com or +new for a new thread whereupon we create a new name). We need to somehow have the thread name passed around with the message, and I'm *guessing* that just putting that metadata in with message is the right choice, but I'm worried that message doesn't seem to have listinf stored so maybe the message is list-independent and could be sent to multiple lists and thus be on multiple threads at once.
(Incidentally, the other stuff we need to store is the user default preference for new threads, which can go in their preferences, and the user/list/thread preference for threads they've specifically subscribed or unsubscribed from, which will have to be a separate table.)
So, um, Barry... where would you prefer that I stick the thread metadata?
Terri

Terri Oda writes:
How is the new name determined?
What happens if you just post to mailinglist@example.com?
Is it possible to split or merge threads?
What happens occasionally on Python lists is that a discussion that originates on one list will propagate to another, then disappear from the first, then come back to the first. (distutils-sig is especially famous for this behavior, with the "other list" being python-dev.)
What behavior would you propose for the dlists in this case?

How is the new name determined? With Systers' current setup, I believe it takes the largest word in the
On 12-11-11 6:31 PM, Stephen J. Turnbull wrote: title (skipping obvious stop words) and adds a 3 digit number if necessary. There might be some truncation if the word is super long and some de-duplication code -- I don't recall the full algorithm.
What it currently does is nothing in particular -- if you add the posting address with the old dlist name in, it would post back to that dlist. If you put in a +new, it would make a new one. If you did no specifying of the dynamic sublist/thread manually, it'll tell you to choose one. I can't think of a better way to handle this off the top of my head for much the same reasons that correctly threading archives is hard.
If we're seriously going to have this replace topics, we might want to make it so something like the existing topic indicators could be tied to a thread somehow too ("topic: dlistthread" headers as an option instead of +dlistthread?) but for a first pass, I just want to do as much of a straight port of the existing code as I can. It's been well user-tested in that state (the systers list being the largest example, with over 3k users and has been running for over a decade) so that's a solid, tested starting point for the Mailman 3.0 implementation.
Incidentally, dynamic sublists are a list-wide setting that the admin would have to enable, the way they're currently written, and that's one of those things I personally would keep the same. Much like topics, dlists do require some training on the part of your users (and from experience, I'd say the amount of training and chasing down the "but you need to post this right next time!" is somewhat similar for dlists and topics) so I wouldn't want to drop people into that unless this is a feature they really want.
Terri

Terri Oda writes:
Is it possible to split or merge threads?
Posters can split off a thread at any time by just replying to +new instead of the existing thread.
So if somebody is subscribed to the old thread, and their default is not to automatically subscribe to new threads, they lose track of the new thread?
There is currently no way to merge threads.
OK. That's hard to do (and keep users happy).
As long as you don't try to support merging threads, and people provide accurate reference or in-reply-to headers, archive threading is pretty much a solved problem AFAIK, as long as you have access to *all* the lists. What's hard to do at the server end is provide killfiles. That's also a solved problem on the client end, but for some reason people want the server to do it for them.

Terri Oda writes:
How is the new name determined?
What happens if you just post to mailinglist@example.com?
Is it possible to split or merge threads?
What happens occasionally on Python lists is that a discussion that originates on one list will propagate to another, then disappear from the first, then come back to the first. (distutils-sig is especially famous for this behavior, with the "other list" being python-dev.)
What behavior would you propose for the dlists in this case?

How is the new name determined? With Systers' current setup, I believe it takes the largest word in the
On 12-11-11 6:31 PM, Stephen J. Turnbull wrote: title (skipping obvious stop words) and adds a 3 digit number if necessary. There might be some truncation if the word is super long and some de-duplication code -- I don't recall the full algorithm.
What it currently does is nothing in particular -- if you add the posting address with the old dlist name in, it would post back to that dlist. If you put in a +new, it would make a new one. If you did no specifying of the dynamic sublist/thread manually, it'll tell you to choose one. I can't think of a better way to handle this off the top of my head for much the same reasons that correctly threading archives is hard.
If we're seriously going to have this replace topics, we might want to make it so something like the existing topic indicators could be tied to a thread somehow too ("topic: dlistthread" headers as an option instead of +dlistthread?) but for a first pass, I just want to do as much of a straight port of the existing code as I can. It's been well user-tested in that state (the systers list being the largest example, with over 3k users and has been running for over a decade) so that's a solid, tested starting point for the Mailman 3.0 implementation.
Incidentally, dynamic sublists are a list-wide setting that the admin would have to enable, the way they're currently written, and that's one of those things I personally would keep the same. Much like topics, dlists do require some training on the part of your users (and from experience, I'd say the amount of training and chasing down the "but you need to post this right next time!" is somewhat similar for dlists and topics) so I wouldn't want to drop people into that unless this is a feature they really want.
Terri

Terri Oda writes:
Is it possible to split or merge threads?
Posters can split off a thread at any time by just replying to +new instead of the existing thread.
So if somebody is subscribed to the old thread, and their default is not to automatically subscribe to new threads, they lose track of the new thread?
There is currently no way to merge threads.
OK. That's hard to do (and keep users happy).
As long as you don't try to support merging threads, and people provide accurate reference or in-reply-to headers, archive threading is pretty much a solved problem AFAIK, as long as you have access to *all* the lists. What's hard to do at the server end is provide killfiles. That's also a solved problem on the client end, but for some reason people want the server to do it for them.
participants (3)
-
Stephen J. Turnbull
-
Stephen J. Turnbull
-
Terri Oda