> While having a single server support multiple domains the way apache
> does would be swell, it's sounding like if these various performance
> issues folks are experiencing aren't resolved first, the
> multi-domain support will be a moot point. The again, I may not
> know what the hell I'm talking about.
Being one of the guys that is really after building/supporting
the multi-domain portion I definately agree that the performance
issues we are talking about here are clearly of more importance.
However, I also see that many of these fields can be developed
somewhat independently of each other. The multi-domain stuff
operates at a much higher level of the code than the performance
issues being addressed here.
I am very much in violent agreement that we must all pool our
talents, and I see many people contributing some very cool
things to the cyrus codebase lately. I'm beginning to envision
a more modular cyrus.
One in which the backend physical mailbox store, the hashing
scheme used for physical disks and many other "algorithms"
that the server uses can all be chosen at compile time (maybe
even run-time for some features).
I see this mailbox-daemon being one more step in that direction.
With a separate server managing the mailbox database, the cyrus
imap/pop3/lmtp processes can be served from a more persistent
backend that can manage large amounts of smart caching, repair
and maintenance on the mail store, even help with the
implementation of spreading the mailstore across multiple
machines. There have been people asking about using cyrus
on CODA and I believe that with the mailbox-daemon interface
becoming well-defined (the LMTP of IMAP so-to-speak) we might
have an opportunity to try it. By separating the cyrus server
from its physical back-end I think we end up with a cleaner
implemented, higher scaling, easier to manage server.
I'm envisioning the Cyrus Murder project actually becoming
unnecessary if this works the way I envision it because the
cyrus imapd process itself ends up becoming little more (if
anything more) than a relay/translator between IMAP the
IMAP client and the backend mailstore. In this sense the
imapd process actually becomes the middle man the MURDER
project was planning to introduce.
I look forward to hearing what Larry and the gang think
of this new introduction.
-- Michael --
