Florian Fuchs writes:
But I also agree with Terri that there might be a good amount of user data used by Postorius, Hyperkitty or any other web ui/client that just doesn't have anything to do with mailman's core tasks. And I don't see why something like "preferred ui theme" or profile-related stuff like "irc nick" should be stored in the core db.
Because there may be multiple clients wanting to access that data.
Isn't it very common that applications combine information from different sources (databases, webservices,...) in one place (with or without caching them locally)?
Yes, in fact it is a common RFE ("I'd like to get general information about our organization members from our organization's membership database and combine it with Mailman-specific information.")
Nevertheless, it would be preferable if that is wrapped in an API that makes it look like it's all coming form one place, and which manages the linkages so that data is not store redundantly in different places, or inaccessible to certain clients. Even UI theme, which you might think would be very specific to each app, is likely to be unified site-wide. At least, site designers will probably want that to be possible.
I just don't think there's all that much data which nobody will ever find a use for sharing it cross-app. So we may as well provide APIs for that sharing from the start.
I don't see anything unusual in the concept of having some mailman-related user data managed by the mailman core and other kinds of data handled by the database/file-structure/key-value-store/web-service(s) that a web application is using.
Common, yes, but the cross-DB linkage problems that arise in that architecture are both predictable and already being observed.
If Postorius and HyperKitty decide to share some information in one place, because the projects are so closely related, that's of course a fine idea. But I wouldn't try to cram everything into the core db just for the sake of having it all in one place.
I don't see any "cramming" here. The point of using an RDBMS (or a derivative such as an ORM or Django itself) is to give the the database a natural structure in multiple tables or objects, while accessing it through a common API.
If the core wants to delegate some DB maintenance to another module or an external app such as an organizational member DB, that's OK, but I think that there should be a central point of contact for all of the data for a given object such as a user.
Steve