Michael Fair wrote:
>
> > 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,
See below.
> - wondering what speed we will lose by having this translation layer,
The greatest perceivable impact (if any) would be seen with LIST/LSUB
just because of the sheer number of mailboxes that it might have to
process. I can't see any other command being impacted my more than
microseconds.
The altnamespace code can definitely be tweaked a little to boost
performance. In fact, if I wanted to change a couple of the existing
function prototypes, I could have written this so that the standard
namespace wouldn't take a performance hit at all (right now, it does a
strdup() per translation). But I didn't want to change too much code at
one time -- keep it simple and functional. I'm sure Larry an I will
discuss some tweaks down the road.
> - being more comfortable with the concept of being able to make
> subfolders of all mailboxes than I am with any folder except INBOX,
Not sure I understand this.
> - preferring that the on-disk structure match the mailstore presentation
> (and being that I prefer the alternate namespace I can't have this),
This is obviously next to impossible when supporting two interchangeable
namespaces.
> - 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
The only place that there are two separate code paths is for LIST/LSUB.
Other than that, any bug will affect both namespaces.
> - and just an overall preference for uniformity so the system isn't
> so complex.
I designed the code so that I had to make as few changes as possible,
both to limit complexity and maintain my own sanity. I haven't checked,
but I'm guessing that I added/changed less than 200 lines of code to
implement altnamespace and unixhierarchysep.
Thanks for the feedback,
Ken
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
