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