[Mailman-Developers] Login / User Identification Issues in MM3

[Barry Warsaw]

On Jul 11, 2012, at 05:04 PM, Richard Wackerbarth wrote:

>As an example, suppose that I want to have an "intelligent" ToDo indicator.
>As a minimum, I need to be able to get from the data store a list of MLs that
>have pending requests AND for which I am authorized to do that work.
>Typically, this would be some kind of join.

This should be hidden behind a REST API.

>Or the "social media" guys might want to add some "respected author" value
>and incorporate that into the way that messages get displayed. That data
>doesn't even exist in the "stock" distribution.

Nor probably, should it.

>I don't pretend to know just what our users will want to add. But they should
>be allowed to write an SQL-type description of their needs and they shouldn't
>"muck" with the inner workings of the message handling schema to do so.

Then, for sites that want that feature, the data should live outside the
core.  As I hope I've explained, that could mean a separate database component
with an alternative IUser (et al) implementation to make the external
queries.  Or it could mean a REST API to push relevant changes in the separate
database component back into the core.

>> The point is that the message distribution agent is mission-critical;
>> if it goes down you are well-and-truly screwed.  If the web UI goes
>> down, it might not even be noticed for weeks.
>
>I don't buy that.  If you advertise a subscribe URL, or any other function,
>that is just as much a "mission critical" component as any other.

But maybe you don't have such a subscribe URL.  I've described several use
cases where such a thing isn't needed.  It must be possible to support both
situations.

>I don't see user passwords providing much direct use in the mail distribution
>system.  They might be critical to a list that requires moderation. But, even
>there, I suspect that the moderators are likely to utilize the web interface.

Users do make changes to their subscriptions, or moderate their mailing lists
through email commands today.  Of course, even that is optional.

>No, I am suggesting that either you implement the functionality by specifying
>that some particular structure be set in a standard database (and provide a
>reference implementation of doing so) or that you specify REST interfaces
>that implement the appropriate functions and REQUIRE that all components
>manipulate that data ONLY through those interfaces.
>
>The REST interface is not a single entity, but a collection of components
>that inter-operate. Each of them is "mission critical".

Agreed.  But the core's REST API should *only* reflect the data model that is
critical to its operations.

In fact, the core already calls out to a REST API to retrieve some
information.  Did you know that the header and footer added to messages is a
resource described by a URL?  Mailman does a GET on that URL with a defined
format to retrieve the appropriate decoration, which it then caches for a
little while.  That's the core making a REST call for data living in an
external system[*].

>Further, "each non-core module will do it differently and incompatibly" is a
>red herring. There MUST be a SPECIFICATION of the interface and EVERY
>implementation MUST meet those REQUIREMENTS. What ever else it does will not
>affect any other part of the system.

Right.  But I would strongly object to that specification in any way being
tied to SQL or a specific database implementation.  HTTP is the language of
the web and REST is a not-perfect but good enough convention built on HTTP.

Cheers,
-Barry

[*] Possibly.  The data may live on an internal-to-the-core resource, which
are defined as mailman:// schemes.  The core doesn't care where the resource
lives, it just does a GET which by definition is REST.