On Tue, 2012-04-24 at 11:12 -0700, Toshio Kuratomi wrote:
[mailman3 core] -- maintainance of list metadata, sending and receiving, provides a REST API [Web UIs] -- web ui to Core functions [Archive-stores] -- stores the messages sent to the mailing lists. Provides a (REST?) API to apps built on top of it [Archiver UIs] -- web ui, nntp interface, REST API (if not implemented at the storage layer), etc to the archive-store
By splitting the archive storage from the archive UI similar to how mailman3-core splits with the web ui, we can allow a sysadmin to choose one archive-storage for all of the archive front-ends that they run on their systems.
Thank you Toshio for explaining this in a better than I was able to do.
Question: Where do we start? I think that we'll either succeed or fail very quickly by trying to define what the API between archive-store and archiver-ui should look like. We'll either be able to agree on a common set of features there (from which we'll be able to go forth and create our own archive-storage plugins) or we'll decide that we all need/want to do different things that no common API can address. If there's no common API definition then we won't be able to do any of the rest of this so there won't be any sense continuing down that path.
The current version of HK relies on mongodb for the storage, but I want to test HK with a traditionnal SQL backend. So I have started to work on this.
The interface I defined is there: https://github.com/pypingou/kittystore/blob/master/kittystore/__init__.py
And its implementation using SQLAlchemy is there: https://github.com/pypingou/kittystore/blob/master/kittystore/kittysastore.p...
The mongodb implementation isn't done yet but should be quite trivial to do (most function from the API were coming from it).
The idea is that now, we can have different backend and each module needing access to the emails can use the API directly without having to bother about which storage system is behind.
I hope this helps,
Pierre