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.