On Jul 12, 2012, at 12:25 AM, Richard Wackerbarth wrote:
On Jul 11, 2012, at 9:05 PM, Barry Warsaw wrote:
There *should* be enough hooks in the system already for a system
administrator to say "I want to use Postorius, so I must enable the Postorius IUserManager implementation".
And, by saying this, you imply that the storage of passwords is no longer the responsibility of "core".
You have delegated it to IUserManager. And the default Postorius compatible IUserManager could store those passwords where ever it wishes. In particular, it can store them in the Postorius User database, along with all of the other User profile information that the site wants to keep. > because everything talks to that object through the interface, and as long as that keeps its contract, the rest of the system should, again Just Work.
Note that when I say IUserManager above I'm talking specifically about the zope.interface that is used in the core. You're talking about a conceptual independent component called a "user manager". The former is a coding specification that contains only the things the core is interested in, it wouldn't be used as an inter-system definition. The latter would be specified by its REST API (let's say). Then the core would have an implementation of IUserManager which maps its data and functionality to REST calls against this external component.
I have no idea whether the above will be easy or not, since nobody's tried it. But the system design should allow you to do it this way, and I would be very open to the right hooks, fixes, and extensions to make this possible. I hope you can see how this approach lets someone run Mailman in many different configurations, from a core-only system, to Postorius, to a system where all the user database is in ZODB or already locked up in a proprietary closed database.
There is another approach of course, which may end up being simpler, if more brittle. You could just try to keep the two databases in sync. It doesn't matter too much which is the master, you just have to decide.
Yes, but from my experience, only with great care. As you note that arrangement is brittle. I would prefer to avoid it.
It definitely means data kept in two places, and you're right that great care has to be taken. What if the core is down for maintenance when a user changes her password through Postorius? These are the kinds of things that the Launchpad integration work addressed, but that was in a highly controlled environment, with lots of operational assurances. In our case, we can't just hand-wave that brittleness away.
I think that this is the wrong approach to the extent that "core", and here, by "core" I think you mean the "admin-by-mail" component, does anything other than call the same REST interface that the web UI would use.
It could, though internally, that would be hidden behind the implementation of IUserManager, IUser, and associated objects. We're saying the same thing but in a different way. The advantage of hiding this behind the zope.interfaces is that we can have multiple alternative implementations of those interfaces, so that whether it's REST or a SQL call doesn't matter to most of the core.
So for example, an IMember associates an IAddress with an IMailingList. The standard implementation of that doesn't use a foreign key between the
member
table and themailinglist
table. Instead it uses the fqdn_listname, i.e. a string.I don't agree. Your string which contains the fqdn_listname IS a foreign key to the mailinglist table. It may not be the primary key in some installations, but it is one-to-one with that key and could be used directly as the primary key.
The point is that it's not a foreign key constraint in the members table. Doing that would, I think, prevent you from putting the mailinglist table in one database and the member table in another. It makes the associated queries less efficient, but provides for a useful measure of flexibility.
Cheers, -Barry
P.S. FWIW, I think this separate "user database" component with REST calls in the IUserManager (et al) implementation would not actually be difficult to mock up. I don't have the time to do the coding, but would be happy to discuss details if someone wanted to take a crack at it.