> My intent right now is to keep the on-disk structure the same, but CMU
> _might_ have different ideas. There has been talk about making '/' the
> default and '.' an option, because it would make the code cleaner and
> possibly a little faster. But, this may or may not ever happen.
So it is essentially a convienence/ROI matter. I can completely
respect that. I just appreciate the fact that it has
been added at all, and in such a way as to be backward
compatible is a bonus. Looking forward long term to the
future I also like to believe that I have fast code and
am not unnecassarily slowing things down to support
features that people don't need/use anymore (more for
elegance and maintainability, and not being constrained
by past features that no longer enhance usability than
for speed purposes).
> I didn't make this happen because I need it (nor does CMU), I basically
> did it because I knew that it would be fairly trivial to build on top of
> my alt-namespace work, and that people want it. Since providing this
> feature any other way would be time consuming, with no immediate benefit
> to the primary developers, this might be as close as it gets to being
> part of the standard distribution.
And you are absolutely right about people wanting it and it being
useful to many of us. I also certainly agree about implementing
it any other way would be time consuming (if for no other reason
than writing a utility to move the old disk structure to the new
disk structure). I suppose I am also bundling in the ideas from
some other patches like the mailboxes.db daemon and the better
hashing algorithm that have been posted recently which really
aren't impacted on way or the other by this, so that concern is
mostly a mute point.
> That being said, I'm curious why you ask. Do you see some inherent flaw
> in the current approach? Or do you just want to make sure that you
> don't get bit by some incompatible change to the on-disk structure?
I suppose there are a number of reasons I ask. A few of them being:
- not wanting to have the code base being weighed against innovation
by having to support legacy design decisions that now cost us
performance,
- wondering what speed we will lose by having this translation layer,
- being more comfortable with the concept of being able to make
subfolders of all mailboxes than I am with any folder except INBOX,
- preferring that the on-disk structure match the mailstore presentation
(and being that I prefer the alternate namespace I can't have this),
- being concerned about having two separate kinds of Cyrus installations
where troubleshooting becomes more complicated because we might
have some bugs that only occur in one namespace while not occuring
in the other
- and just an overall preference for uniformity so the system isn't
so complex.
Most of these are just FUD and personal preference. I have
always liked and admired cyrus for the speed with which it
gets the job done and would hate to see that slowly creep
away as things move forward. I'm grateful to everyone who has
contributed to Cyrus, and am just as interested in having the
best IMAP mail server out there as the rest of us. So when I
saw the changes being made I got both excited and a little
concerned. I'm also the guy who thinks we should have a
directory actually named "inbox" on-disk and that the folder
with the username is really just a container for sub-folders.
I believe that will help increase the speed and simplicity of
the system, hopefully making it easier for guys like myself
to get started with the code base to help make changes and
enhance the system.
Thanks for reading,
-- Michael --
