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. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9