[Mailman-Developers] Architecture for extra profile info

[Barry Warsaw]

On Apr 19, 2013, at 07:18 AM, Richard Wackerbarth wrote:

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

It's always been part of my thinking, and it's most evident in the use of
interfaces internally.  Time will tell whether we've accomplished that or
not.

However, it's also important to realize that probably the vast majority of
users who roll their own just install what we give them and go (well, most
likely with their stack of distro patches).  So I think in that case, it still
makes sense for the core to provide, by default, a minimally useful user
database, as it does today.

>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?

It's a great question, which I cannot answer.  My opinion is that we have to
let such enterprise users drive that development, while we give them an
architecture that supports their use cases.

>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.

Our users (specifically IUser) is extremely minimal.  A user consists of a
display name, a password[1], an id, and a "created on" date.  There are some
additional methods or properties which are just convenient APIs for queries
and membership updates, but really it's not much more than a way to collate a
set of registered addresses under one unit.

-Barry

[1] With Persona, we can *probably* get rid of the password.  It's only going
to be used to do authenticated email commands, but it sucks for security.
It's also probably true that few people actually use the email command
interface - heck even I rarely use it.  It's important to keep, but I think it
would be better to base that on OpenPGP rather than plain text passwords.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130419/4433489b/attachment.pgp>