Stefan Tatschner writes:
This architecture might scale wonderfully for large and distributed systems, but it is questionable for low traffic sites. Maintaining multiple databases (or call it broker) for a few small mailing lists is just too much.
But the problem this thread is talking about arises precisely when you use a simple single-database approach. I'm not saying there is no way to optimize the current architecture, but this is what we have.
Unfortunately the original developers did the work for their employer, and no longer have that support. Looking at the git log, every year since support ended there's a spate of commits in the summer. If you want to write up an RFE in a paragraph or so and post it to the gitlab tracker, this might make a good Google Summer of Code proposal -- we'd have support for an intern and the experts would be more available for consultation. We didn't participate last year, but we've had good success in getting projects approved in the past.
Note that if we get GSoC support, the student is responsible for planning detailed requirements and design. (For example, there may be better backend databases, or we could implement a cache of some kind in HyperKitty itself. That level of detail isn't needed yet.) I believe that there's also an active third party project to work on the UI of HyperKitty, so maybe we can make this the Summer of HyperKitty.
-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: firstname.lastname@example.org University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN