[Mailman-Developers] Architecture for extra profile info
Stephen J. Turnbull
stephen at xemacs.org
Sat Apr 20 06:40:42 CEST 2013
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.
More information about the Mailman-Developers
mailing list