[Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

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.