Archie Singh via Mailman-Developers writes: > I get it and you are right, a better use case would be some kind of > user support lists where users maybe wish to follow some particular > troubleshooting thread than core developer lists (as every thing is > lowkey interconnected here)
Exactly. I don't think it was you, I wrote to someone that the original use case was basically as an issue tracker. There's be a project list, the main line was discussions of architecture, UX, look-and-feel, etc, and specific tasks (fixes or features) would fork off a sublist. > This is my fault, I was working from the gsoc hour targets That's kind of an "attractive nuisance" (like a backyard swimming pool with no fence that toddlers fall into) in the way the program is set up. > So, if I am understanding correctly, you mean i should disregard > building a new db schema to track the message_id and instead think > of dynamic sublists as a mailinglist object in itself with a > (parent) id that points to the main list (and the subscription > relationship (address id linked to mailinglist) is standard mailman > convention). Yes. I think that is sufficient to get a good match to the original feature implemented by the Systers. > Although, if a sublist is supposed to be dynamic then should this new child > mailing list object be produced as soon as someone adds a -follow (assuming > addition to email cli) command on a thread...as opposed to an admin having > to create it manually? The original concept was entirely email-based. Systers is a global organization with a lot of members in places that did not have reliable Internet, a web-based workflow was not viable for some of their projects. They did add web UIs over time, but the core concept was all email. I believe the original UI was (using this list as the parent, and "xyz" is a random token) - mail to [email protected] forks off a new list [email protected] - The -new mail contains the description of the sublist, and it is sent to both mailman-developers and to - Users join the new list by sending mail to mailman-developers-xyz-join and the rest of the administrative addresses work in the same way > Okay, so to preserve the existing ux patterns, the subscription should be > directly linked to the address object within the context of the child list > object "Subscription" is a Python class in Mailman core. It has attributes for the Address and the MailingList that are subscribed, as well as the subscription's configuration of the user parameters like no-mail. By default these are all set to "inherit" (from the MailingList settings, the Address settings, or the User settings). > Naturally. I was applying the social media model to mailing lists (i just > got carried away)...do you think (as stated on the website for proposal > ideas) that lookign at the original anitaborg/systers implementation of > dynamic sublists built on mm2 (and i do understand that mm2 and mm3 have > very different architectural patterns) would help me understand the user > experience and email commands to trigger sublists...or should I just think > about the command flow (and ux) from scratch for mm3? I think you should definitely look at their implementation to understand the email command interface and how a sublist gets set up, and populated with subscriptions. I don't think having a web UI will constrain that much at all. If you have original ideas, let's discuss them. But (at least in past years) architecture isn't your job in GSoC -- if you want to model the Systers implementation as closely as possible, that's entirely consistent with the intent of the GSoC rules. Mailman 3 adopted a lot of architectural features from Mailman 2. In particular, the MailingList, Address, and Subscription classes are largely unchanged. Addition of the User class to manage authentication and Addresses, and splitting the pipeline of handlers into Chains of Rules (moderation, basically) and Pipelines of Handlers (message modification, generation of recipients, and actually sending mail) are big changes but they didn't affect the core user-visible objects except for the introduction of Users, and Users don't affect the semantics of relations among MailingLists, Addresses, and Subscriptions at all. > > I think the answer to that is "it's just handled like a list". > > understood, considering the sublist is itself a mailing list, it has its > own pipeline...so no need to build a custom handler to inject in the main > pipeline to do set intersections at all. The standard handler that deals > with returning the address ids will pull the addresses subscribed to that > child list (if my earlier assumption about child list objects was right) The database implementation is *really* different. In Mailman 2, it was hierarchical: The mailing list object had a roster attribute, and the roster contained subscriptions, which had addresses (just strings) and various user options for the subscriptions. In Mailman 3, addresses are rows in one table, mailing lists are rows in another, and subscriptions are a many-to-many relation (table) joining addresses and lists. And a database manager like PostgreSQL is built to handle billions of such rows in each table (Apple has billions of users so they may actually have a database that big!!) But then you realize that subscriptions are just rows (and pretty short ones, at that) in a long table and a mailinglist only uses a few of them. A sublist is just a mailing list with a parent that gets its roster from SELECT * FROM mailinglists WHERE posting='[email protected]'; suddenly the idea that a sublist is just a mailing list doesn't seem so odd. Steve -- 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
