[hyperkitty-devel] Merging HyperKitty and KittyStore

Aurelien Bompard abompard at fedoraproject.org
Mon Jan 12 13:56:03 UTC 2015

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 !

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/hyperkitty-devel/attachments/20150112/aef01d81/attachment.html>

More information about the hyperkitty-devel mailing list