Hey y'all,

After giving it much thought, I'm about to start merging HyperKitty and KittyStore. But before I do that, I'll present you my arguments and would be very happy if you had comments on them or on this change in general. After all, I can't see all ends :-)

Arguments for the merge:
- Doing database requests in two different ORMs (Django/SQLAlchemy) is error-prone, because results are sometimes similar in behavior and sometimes not.
- Kittystore is just a library anyway, which reads HK's configuration, and Mailman is hooked into HyperKitty directly, so it's all very linked (can't be on different VMs).
- Sharing the caching engine is a real pain
- The class API in KS's store.py has to be regularly updated to accomodate for HyperKitty's needs, and is currently just a large number of methods returning the result of simple requests, often where only parameters differs. It's going to be a maintenance nightmare.
- Noone else uses KittyStore, and if someone wants an access to the stored email it's either going to be via REST, or we'll extract and design the API then, when we have real requirements and not supposed ones.
- HK and KS must evolve at the same time to keep compatibility, so there's no interest in separating one from the other to make the installation and upgrade more flexible
- KS will now require a REST server and a background daemon to serve it, and HK already has that.
- HK needs to have background operations capabilities to generate archive mboxes, so background operations currently in KS can be migrated there
- Configuration and installation will be much easier, and the system will be simpler to understand for administrators

Arguments against the merge:
- Load from long-running operations in Kittystore will not impact the webserver (except for shared resources like CPU or DB server)
- The "push" path coming from mailman is better conceptually separated from the "pull" path coming from the web
- Another application could, one day, import KS and query the DB without importing HK (but today the API is not stable enough)
- If the webserver is down, Mailman can still archive the messages (comment: but failure to archive is already backed up by the shunt queue in mailman, and this argument is obsoleted by the new requirement of a REST server in KS)
- Permissions on KS's REST server will be simpler since it can just listen on localhost (comment: that's easy to limit in Django too)


Any other comments on those arguments? Am I missing something?
Thanks !

Aurélien