[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Barry Warsaw writes:

 > but also remember how much pain we had at the sprint trying to get Postorius
 > and HyperKitty deployed together (how's that coming by the way?).

I got mail from Yarko, does that help? :-)

I hope to get back to that this week, now that I've initialized my
classes.  Dunno if Yarko has done anything, or if anyone else is
working on it.

 > Eventually OAuth is a good idea and I'm not aware of anything else
 > that fits the bill as well, for authenticated scripting of REST
 > APIs.  But we probably don't need it for now.

We don't *need* anything we don't already have :-), but I'd like to
see OAuth and Persona for subscribers.

 > One important requirement is that for any data that is kept in both the core
 > and the user database, we must have a way of keeping them in sync.  The
 > easiest way of doing that I think is to allow two way communication between
 > them so that if data changes in the core (e.g. an address gets verified by
 > reply instead of link-click), the core can inform the user database of this
 > event.

This isn't going to fly for enterprise usage.  I mean, you can inform
the enterprise DB, but it's highly unlikely to do anything useful with
the information.  I think in the core "user" has to be a rather
abstract class, which provides links to profile information (perhaps
in a Mailman-supplied component, or in an enterprise DB, or both[1]),
and to list-related information.

Footnotes: 
[1]  UI note: if both, enterprises may want "official" information to
be visually distinguished from "unofficial" information.