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

[Stephen J. Turnbull]

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.

 > > It's not the same argument.  A mailing list needs a message
 > > distribution agent; it doesn't *need* a webUI.
 > 
 > In this day and age, try selling that one! Only those of us, and
 > that especially includes me, who were around "way back when",
 > before http even existed, know any other way. :)

So what?  The fact that a webUI is very convenient is not the point.
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 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.  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.  In
fact, as you point out, they already are different and incompatible.
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?

 > I view your argument as the message handler claiming "I'm special!

It is.  First, it is mission-critical; nothing else is.  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.

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

 > -- IMHO, the tail is wagging the dog.

Call it "claim" if you like, but the message handler is the dog.

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

Steve