[Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Barry,

Are you starting to come around to the concept that I have been advocating for a long time?

In particular, rather than "owning" the user information, "core" simply views it.

I assume that you are reluctant to store "foreign keys" to external databases because you worry that consistency might be broken when another process alters the database.

I ask that you consideration the following as it applies to that view:
First, as viewed from the other side (the enterprise, etc.), your same concerns apply to accessing their "user". For example, when you store the user password, how do they assure availability and consistency?

Second, particularly if you separate the administration functions, "core" message handling should, at most, rarely care about the "user" information. The subscription information, which seldom changes, should contain sufficient information to handle the time-critical task of message dispatch.

Richard
 
On Apr 18, 2013, at 8:20 PM, Barry Warsaw <barry at list.org> wrote:

> Terri, thanks for kicking off this discussion!
> 
> On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:
> 
>> On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
>>> Main comment: Sounds like LDAP to me.
> 
>> Actually, this is a really important comment.  I was sort of wondering that
>> too when I started writing the description.  LDAP is a moderately frequently
>> requested feature already.  Would it make sense to use that probably rather
>> than rest, or make a rest framework that talked to ldap under the hood?
> 
> I agree that this is a really interesting suggestion.
> 
> What's interesting to me about it is that this acknowledges that
> administrative control of this extra user information may fall to folks not at
> all directly involved in mailing list administration.
> 
> You can imagine that a company would already have their LDAP database of
> additional user information, from postal addresses, to phone numbers, to IRC
> handles, pictures and icons, birthdays, etc.  Further, I can imagine that if
> that company were to be running MM3 and HyperKitty, they'd probably not want
> to duplicate that information in multiple databases, they'd just want to pull
> the pictures and IRC nicks out of LDAP.  For their purposes, their LDAP
> database *is* their user database.
> 
> Of course, some of that information may also be used in part or in whole for
> the core, e.g. display names (which actually are useful in places, such as
> crafting the From header for a virgin notification).
> 
> Now, at least conceptually, I've always thought about the user database as one
> of the three pillars of information in the core, the other two being the list
> database and the message store.  This is why for example subscriptions do not
> just link a foreign key for the mlist to a foreign key to the address, because
> this would not allow for separation of these two pillars[1].
> 
> Furthermore, the use of interfaces internally is meant to allow for
> alternative implementations of the lowest database layer of these pillars,
> without affecting any functionality above it.  So let's say even in the core,
> user passwords, display names, and preferences were kept in LDAP.  An
> alternative implementation of user.py would pull the data in from there and as
> long as it satisfied the syntactic and semantic APIs of the IUser interface,
> everything else in MM3 would continue to work.
> 
> You could extend this to the idea expressed elsewhere that the core could use
> this external user database.  Why not?  The external user database could be
> accessible over REST or a via a database server, etc.  We'd need an
> implementation of the underlying data objects that could talk to this user
> database and satisfy the interfaces, and that should be all you'd need.
> Making it performant enough for the core is just an engineering exercise
> <wink>.
> 
> -Barry
> 
> [1] Whether any of this works or has the right separation is another matter
> entirely. ;)  For example, looking at it now, I'm not so sure Members
> shouldn't be part of the MailingList pillar rather than the user database
> pillar.
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at 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/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9