Tejas Pavan B via Mailman-Developers writes: Please trim your posts of Gmail detritus.
> The Mailman 2 implementation is interesting in how it handled the > two-recipient-set problem. Instead of filtering the outgoing > message, it created two altered messages from the original and > placed them into a dedicated Dlist queue — one for subscribers to > new conversations and one for members who had explicitly opted into > the thread. The original message was archived only. This neatly > avoided the incoming pipeline's single-message assumption. Yes. I think that is a good design. > For Mailman 3, my initial thought is that the equivalent behavior > might live in two places. First, a new subaddress command `+new` This should be `-new`, to follow the existing email commands. We may need to distinguish that from `+$one-time-cookie` for the address validations and the like. > in the command runner — following the existing `join`, `leave`, and > `confirm` subaddresses — could intercept messages sent to > `listname+new@domain` and create the sublist. Second, replies could > be routed through a delivery check before `CookHeaders` that > evaluates per-member, per-thread subscription state to determine > the two recipient sets. I think you're thinking in terms of the Mailman 2 architecture. In Mailman 3, both of these would be split between a chain (to classify the message) and a handler (to do operations, including side effects on the database). > This raised a design question I wanted to ask on-list. > > The Mailman 2 implementation stored per-conversation subscription > state in a separate PostgreSQL database per list. For Mailman 3, > would the preferred direction be: > > 1. Introducing a new `ConversationSubscription` model in the core > database (member × thread × subscription_state), or > 2. Extending the existing `IMember` / delivery preference > infrastructure with a per-thread layer? It's not obvious to me that a "sublist" needs to be treated as anything but a MailingList to start with. The next step would be for the REST API to grow a no-sublist filter, so that random users who visit the list of lists page see only top-level lists. Then add sublist APIs. Then add Postorius options so that top-level list owners and maybe subscribers and maybe everyone can see sublists. The main problem is who can create sublists (should that be moderated? by whom?), and who owns the sublists (note, there can be multiple owners). Note that the above suggestion (only a suggestion!) imposes a tree structure on sublists (or maybe a DAG, I *think* it would not be to hard to "join" two sublists or a sublist to its parent list, but that's probably out of scope for this task). We need to consider whether there are use cases where tree structure would be bad. My quick opinion is that the tree structuring is a *good* thing, we don't want people creating effectively "top level" lists other than the superuser or domain owner. > Option 1 feels conceptually cleaner to me because it keeps > conversation-level state separate from member-level state and > avoids overloading `delivery_status`, which is currently a > per-member, per-list setting with no notion of per-thread > granularity. However, option 2 would reuse more existing > infrastructure. I agree this needs discussion. However, IIRC, in Mailman 2, all subscriber configuration (except optionally password, and even that was fragile) was per-subscription. In Mailman 3, we have a User > Address > Subscription hierarchy, so that in almost all cases the User specifies the options, and at run time the Subscription defers to the Address defers to the User. So I don't think "overloading delivery status" is the issue in Mailman 3 that it was in Mailman 2. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
