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

[Richard Wackerbarth]

On Jul 11, 2012, at 3:29 PM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> No! Although you are making available (some/most/all) of the data
>> values, you are not making available the ability to make arbitrary
>> SQL-type queries to view the data.
> 
> AFAIK the plan is to do that via the REST interface.  I don't see why
> they need to be "arbitrary SQL-type" queries; you need to be a bit
> more explicit about that.

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

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

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.

>> I think we MUST assume that there will be a web interface.
> 
> Of course there will be a web interface.  As you point out, we
> couldn't even give away the product without it.  But there might be
> half a dozen different ones, too.
> 
>> As far as the complexity of access is concerned, the mail handler
>> probably has the lowest requirements. The present architecture
>> would have to be extended significantly to provide for appropriate
>> handling of ALL of the data. That includes a much richer query
>> capability.
> 
> So what?  This extension needs to be done *somewhere*; you aren't
> going to be able to avoid it by throwing it out of the core.

No, but I will "compartmentalize" it.

>  What you are going to be able to do by throwing it out of the core is ensure
> that each non-core module will do it differently and incompatibly.

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

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.

>  In fact, as you point out, they already are different and incompatible.

That is because you have not followed the principles and allow "someone else" to provide that service.

> I don't see any reason for that to change unless the DB API is
> centralized somewhere.
> 
> I see no reason for that somewhere to be anywhere but the core.  The
> core is the only component that we *know* *has* to be there, and there
> will be only one implementation of it.  The various UIs have
> substitutes, and one reason for splitting them out was to make it
> possible to have multiple implementations (and you've been at pains to
> point that out).

>> Presently, the message handling is integrally tied to the database
>> implementation. Customization extensions will intrude into parts of
>> the system which they should not affect.
> 
> Why?  Parts of the system that don't need them just ignore them.
> Where's the problem?

Spaghetti. In any system of complexity, there will be parts that could care less about the details of most other parts.
design modularity practices separate those parts and provide limited access between them.

>> I view your argument as the message handler claiming "I'm special!
> 
> It is.  First, it is mission-critical; nothing else is.

And the underlying RDBMS, the MTA, etc. are not?

>  Second, it
> does need to ensure good performance, which I doubt is true of other
> components.  Whether that justifies bypassing the REST API or
> whatever, I don't know.

The question is whether particular data is local or shared. If I, as one of the data consumers, don't need access to some of the data, there is no reason to attempt to expose it via REST. Therefore, even if "maintain ..... (certain data)" is a part of the specification, how it is maintained is an internal detail.

>> Everyone else has do do things my way. I get special privileges."
> 
> Well, you've misunderstood me, then.  My intention is that the message
> handler use the same APIs available to everybody else, except that
> other applications might need to use the REST interface where the core
> might have more direct access.

This is my objection. IF some particular data is exposed, then it should be maintained by one handler, without back doors.
If that handler is local, then the interface need not serialize the data and transmit it, but the access should be isomorphic to doing so.

>> -- IMHO, the tail is wagging the dog.
> 
> Call it "claim" if you like, but the message handler is the dog.

With respect to messages, yes. But not with respect to credentials.

Credentials should be kept in a separate box. And that box should be kept where ever it best fits in the overall data flow. From a design perspective, it should be easy to place it anywhere the installer desires.

>> Let's split shared data storage from the message handler,
> 
> I don't have a problem with that as a matter of design, but for
> distribution it will be bundled with the message handler.  That's not
> necessarily true of other components.

For distribution, a reference implementation of EVERY interface should be included.

And substituting a different implementation should be a simple as excluding the distribution version and dropping in the alternate.

> Steve