[Mailman-Developers] Login / User Identification Issues in MM3

[Stephen J. Turnbull]

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