Stefan Tatschner writes:
This architecture might scale wonderfully for large
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
Faculty of Systems and Information
Email: turnbull(a)sk.tsukuba.ac.jp University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN