Archie Singh via Mailman-Developers writes:
> So the workflow is basically an email-native issue tracker where specific
> tasks fork off into tokenized (-xyz) child lists so the users can join and
> leave (intuitively too)...
Yes.
> although it makes me wonder whether if there are too many of the
> -xyz sublists created, then if the people are using these for every
> little troubleshooting task won't the database be overflowing with
> soo many of them?
SQLite3, maybe. PostgreSQL or MySQL? Are you kidding? "Hulk
Database, Hulk crunch data!!"
Regarding the UX, if issue tracker is the use case, then, no, that's
by design. Other use cases for the feature, we'd have to see.
> when postorius asks for the directory of mailinglists, should core
> be hiding these lists by default so the ui doesn't get cluttered?
> or is it better if the core just sends everything and lets the
> frontend do the filtering?
(1) I expect the sublists feature to be off by default for most lists,
there shouldn't be that many lists to start.
(2) I envision a list of lists with the sublists collapsing into their
parents by default, and a widget to expand or collapse sublists.
So send them all. Optimize later (eg, send by pages in the
background, etc.)
> So as the subscription class already handles inheritance by default,
> attaching an address to a newly generated child list should pull the
> required parameters( without the heavy replication)
Subscription configurations are kept anonymously in a separate table.
The subscription schema has a pointer (actually, row id) to a
configuration. IIRC in fact the same table serves for Users,
Addresses, Subscription, and List-Fallback configurations.
The SQLAlchemy ORM makes it pretty easy and intuitive to do stuff as
relations and joins. This results in quite efficient storage for
graph models that you get with a Python object database.
There are a number of places where things get nasty when you get
"large" numbers of objects (several thousands, say) but those mostly
affect Postorius because of network bandwidth, not so much core.
This is a new, optional feature. Don't even think about optimizing
(that's extreme but you see my point, right?) until you've completed
both the feature (including tests and documentation) and we've got a
serious MR for integration into the trunk ready.
--
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
