Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
On Monday, July 9, 2001, at 10:40 AM, Greg Hewett wrote: > I have a different problem with the MacOS X Mail. I cannot view > messages in a mailbox that has subfolders. i.e. INBOX. I see my > lowest level subfolders fine. I believe this is a known "feature" of the MacOSX client - a mailbox can contain subfolders or mail but not both, clare
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
I have a different problem with the MacOS X Mail. I cannot view messages in a mailbox that has subfolders. i.e. INBOX. I see my lowest level subfolders fine. > Sorry for the ambiguity. The problem lies in the MacOS X Mail client, > NOT in cyrus. When you try and select a subfolder, you get an error > back that "folder/subfolder" is not an acceptable mailbox name to the > server. Well, of course it's not! :-) alt namespace was required > before I could look at anything other than INBOX because, for example, > I would get an error saying that it couldn't select "INBOX/Sent". Now > I can get to all of the first level folders because they can be > selected without >separator chars, but I anticipate that I will be able to get to all of >them with the unix separator patch. But if Apple had been able to read >an RFC, none of it would be necessary at all.
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
--On Friday, July 06, 2001 12:48:13 PM -0400 Ken Murchison <[EMAIL PROTECTED]> wrote: >> Hey great! This will let me work around MacOS X's Mail program's >> stupidity in this regard. Before I set up alt namespace, I couldn't get >> to any of my folders besides the INBOX! Doesn't anyone read an RFC >> anymore before they write software? Sheesh. > > Who? Me or the Mac guys? > > Are you saying that the server doesn't display them or allow access to > them, or that your client can't deal with the namespace/hier-sep change? Mac OS X's Mail is evolved from Mail.app in NeXT/OPENSTEP. I don't remember IMAP being supported in OPENSTEP 4.2, so this is something that Apple added. I am running Cyrus v1.5.19 and Apple's Mail _does_ have problems with it. I can see the entire hierarchy, but can't access anything but INBOX. Other mail clients do not have these troubles with this server, so I can pretty safely say that it's Apple's problem. :-) I would bet that nobody at Apple ever thought that someone would be silly enough to use a "." as a separator. hehe They probably got as far as UW and stopped there once things "worked" with it.
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Michael Fair wrote: > > Thanks for all the clarifications. > > To finish up on a point that you didn't fully understand > and to make a recommendation for your evaluation, > > > > - 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. > > Right now we can create subfolders of INBOX but not folders at > the same level as INBOX. With the ANN we can create folders at > the same level of INBOX but not subfolders of INBOX. > > I am more comfortable with an implementation that allows > for the creation of folders and sub folders wherever the > admin or user determines is appropriate without regard to > whether the folder is named "inbox" or "foo". I'm not sure that I see the need for both at the same time, but OK. > > > - 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. > > True, but I don't think it would be very difficult to support > both at the same time if we were willing to make a minor on-disk > modification to add a folder called "inbox" underneath the folder > "username". It seems to me that if we made INBOX an actual > folder on-disk (lower cased of course) rather than a synonym > for "username" all the problems with separate namespaces would > go away. All folders created at the top level would appear at > the top level including INBOX, and any subfolders of INBOX > could be created there. Interesting idea, that would solve the "can't create folders under INBOX" problem with alt-namespace. Something to think about. 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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Thanks for all the clarifications. To finish up on a point that you didn't fully understand and to make a recommendation for your evaluation, > > - 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. Right now we can create subfolders of INBOX but not folders at the same level as INBOX. With the ANN we can create folders at the same level of INBOX but not subfolders of INBOX. I am more comfortable with an implementation that allows for the creation of folders and sub folders wherever the admin or user determines is appropriate without regard to whether the folder is named "inbox" or "foo". > > - 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. True, but I don't think it would be very difficult to support both at the same time if we were willing to make a minor on-disk modification to add a folder called "inbox" underneath the folder "username". It seems to me that if we made INBOX an actual folder on-disk (lower cased of course) rather than a synonym for "username" all the problems with separate namespaces would go away. All folders created at the top level would appear at the top level including INBOX, and any subfolders of INBOX could be created there. We do have a problem to address with existing implementations. I could see this addressed in one of two ways: 1) Write a simple script that creates a directory called "inbox" underneath "username" and moves all entities from within "username" into "inbox" 2) Use an imapd.conf flag which controls using either the current code of "inbox.foldername"="username/foldername", or the new code which says "inbox.foldername"="username/inbox/foldername". This would of course be down the road because I have no desire to mess with existing installations at this time. However, it does seem to me that if we added a folder named INBOX at the appropriate place and renamed the separator "/" than we would have simplified the whole operation of the system and supported both namesapce options all at the same time which seems like a very inexpensive modification to make to me. -- Michael --
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
From: "Michael Fair" <[EMAIL PROTECTED]> Date: Sat, 7 Jul 2001 13:24:04 -0700 [...] This is pretty much what I was expecting. I would also imagine that without a good tool migrate several thousands of mailboxes changing the on-disk structure is not really an option. I personally believe that we would see a performance gain by changing the on-disk structure, but believe that can also be delayed till some time down the road. Without actual benchmarking, it's really impossible to say that the performance of the alt-namespace code is a concern. Regardless, we will not be dropping support for the old namespace or the old hierarchy seperator any time soon. Understanding the allocation patterns and improving them would probably improve speed more (though the namespace stuff undoubtably adds malloc() calls). libsasl v2 goes part of the way to reducing random mallocs. Minimizing disk i/o is a much bigger win. For instance, making cyrus.cache include the entire header (not just selected portions) and removing some of the pre-parsed gunk would probably increase speed dramatically for Outlook/Outlook Express/Mozilla clients. Threading/servicing multiple clients from a single process is another obvious place for improvement. Larry
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
>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. > > I think performance is the only reason to change the on-disk > structure. > > Since we're unlikely to switch to / soon, I have an organizational > bias to keep with what we have now. If the code gets simplier and > faster switching, we'll evaluate that. > > But we'll probably stick with this general idea for the near future. This is pretty much what I was expecting. I would also imagine that without a good tool migrate several thousands of mailboxes changing the on-disk structure is not really an option. I personally believe that we would see a performance gain by changing the on-disk structure, but believe that can also be delayed till some time down the road. -- Michael --
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
> 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 --
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Date: Sat, 07 Jul 2001 09:29:44 -0400 From: Ken Murchison <[EMAIL PROTECTED]> Organization: Oceana Matrix Ltd. 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. I think performance is the only reason to change the on-disk structure. Since we're unlikely to switch to / soon, I have an organizational bias to keep with what we have now. If the code gets simplier and faster switching, we'll evaluate that. But we'll probably stick with this general idea for the near future. Larry
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Michael Fair wrote: > > > I am pleased to announce the availability of a selectable hierarchy > > separator for Cyrus IMAP. Up until now, Cyrus used a netnews-style > > hierarchy, where '.' was used as the hierarchy delimiter -- thus > > prohibiting '.' from appearing in mailbox names. This release allows a > > UNIX-style '/' separator to be used in the same fashion that David > > Fuchs' (and derivative) patches. > > Out of curiosity, is the Alternate Namespace approach > so as not to affect the on-disk structure going to be > the permanent future of this patch or this an interim > approach to maintain backwards compatibility while we > transition our installations? > > I'm assuming the latter, but before I get too far > ahead of myself I thought I'd better ask. 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. 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. 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? Thanks, 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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
> I am pleased to announce the availability of a selectable hierarchy > separator for Cyrus IMAP. Up until now, Cyrus used a netnews-style > hierarchy, where '.' was used as the hierarchy delimiter -- thus > prohibiting '.' from appearing in mailbox names. This release allows a > UNIX-style '/' separator to be used in the same fashion that David > Fuchs' (and derivative) patches. Out of curiosity, is the Alternate Namespace approach so as not to affect the on-disk structure going to be the permanent future of this patch or this an interim approach to maintain backwards compatibility while we transition our installations? I'm assuming the latter, but before I get too far ahead of myself I thought I'd better ask. -- Michael --
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Nick Sayer wrote: > > Ken Murchison wrote: > > > > > Nick Sayer wrote: > > > >>Ken Murchison wrote: > >> > >> > >>>Nick Sayer wrote: > >>> > Hey great! This will let me work around MacOS X's Mail program's stupidity > in this regard. Before I set up alt namespace, I couldn't get to any of my > folders besides the INBOX! Doesn't anyone read an RFC anymore before they > write software? Sheesh. > > > >>>Who? Me or the Mac guys? > >>> > >>Sorry for the ambiguity. The problem lies in the MacOS X Mail client, > >>NOT in cyrus. When you try and select a subfolder, you get an error back > >>that "folder/subfolder" is not an acceptable mailbox name to the server. > >>Well, of course it's not! :-) alt namespace was required before I could > >>look at anything other than INBOX because, for example, I would get an > >>error saying that it couldn't select "INBOX/Sent". Now I can get to all > >>of the first level folders because they can be selected without > >>separator chars, but I anticipate that I will be able to get to all of > >>them with the unix separator patch. But if Apple had been able to read > >>an RFC, none of it would be necessary at all. > >> > > > > I'm confused. Are/were you running a patched version of Cyrus that > > created folders with '/' as the separator? My stuff is NOT compatible > > with anything that actually stores folder names containing '/' in the > > mailboxes DB (like David Fuchs' patch). The whole premise of my > > alt-namespace and hier-sep is to not change any of the on-disk files. > > No. It's just cyrus with the namespace patch. > > MacOS X's mail client is stupid. It tries to do a > > 10 SELECT INBOX/foo > > despite the fact that the LSUB/LIST output said "INBOX.foo". > > This behavior is clearly stupid. Ahh! Now I understand. > You're being blinded by an expectation that the client was not written > by morons. :-) Yes, but now I have seen the black light ;-) -- 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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Ken Murchison wrote: > > Nick Sayer wrote: > >>Ken Murchison wrote: >> >> >>>Nick Sayer wrote: >>> Hey great! This will let me work around MacOS X's Mail program's stupidity in this regard. Before I set up alt namespace, I couldn't get to any of my folders besides the INBOX! Doesn't anyone read an RFC anymore before they write software? Sheesh. >>>Who? Me or the Mac guys? >>> >>Sorry for the ambiguity. The problem lies in the MacOS X Mail client, >>NOT in cyrus. When you try and select a subfolder, you get an error back >>that "folder/subfolder" is not an acceptable mailbox name to the server. >>Well, of course it's not! :-) alt namespace was required before I could >>look at anything other than INBOX because, for example, I would get an >>error saying that it couldn't select "INBOX/Sent". Now I can get to all >>of the first level folders because they can be selected without >>separator chars, but I anticipate that I will be able to get to all of >>them with the unix separator patch. But if Apple had been able to read >>an RFC, none of it would be necessary at all. >> > > I'm confused. Are/were you running a patched version of Cyrus that > created folders with '/' as the separator? My stuff is NOT compatible > with anything that actually stores folder names containing '/' in the > mailboxes DB (like David Fuchs' patch). The whole premise of my > alt-namespace and hier-sep is to not change any of the on-disk files. No. It's just cyrus with the namespace patch. MacOS X's mail client is stupid. It tries to do a 10 SELECT INBOX/foo despite the fact that the LSUB/LIST output said "INBOX.foo". This behavior is clearly stupid. You're being blinded by an expectation that the client was not written by morons. :-)
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Nick Sayer wrote: > > Ken Murchison wrote: > > > > > Nick Sayer wrote: > >>Hey great! This will let me work around MacOS X's Mail program's stupidity > >>in this regard. Before I set up alt namespace, I couldn't get to any of my > >>folders besides the INBOX! Doesn't anyone read an RFC anymore before they > >>write software? Sheesh. > >> > > > > Who? Me or the Mac guys? > > Sorry for the ambiguity. The problem lies in the MacOS X Mail client, > NOT in cyrus. When you try and select a subfolder, you get an error back > that "folder/subfolder" is not an acceptable mailbox name to the server. > Well, of course it's not! :-) alt namespace was required before I could > look at anything other than INBOX because, for example, I would get an > error saying that it couldn't select "INBOX/Sent". Now I can get to all > of the first level folders because they can be selected without > separator chars, but I anticipate that I will be able to get to all of > them with the unix separator patch. But if Apple had been able to read > an RFC, none of it would be necessary at all. I'm confused. Are/were you running a patched version of Cyrus that created folders with '/' as the separator? My stuff is NOT compatible with anything that actually stores folder names containing '/' in the mailboxes DB (like David Fuchs' patch). The whole premise of my alt-namespace and hier-sep is to not change any of the on-disk files. 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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Ken Murchison wrote: > > Nick Sayer wrote: >>Hey great! This will let me work around MacOS X's Mail program's stupidity >>in this regard. Before I set up alt namespace, I couldn't get to any of my >>folders besides the INBOX! Doesn't anyone read an RFC anymore before they >>write software? Sheesh. >> > > Who? Me or the Mac guys? Sorry for the ambiguity. The problem lies in the MacOS X Mail client, NOT in cyrus. When you try and select a subfolder, you get an error back that "folder/subfolder" is not an acceptable mailbox name to the server. Well, of course it's not! :-) alt namespace was required before I could look at anything other than INBOX because, for example, I would get an error saying that it couldn't select "INBOX/Sent". Now I can get to all of the first level folders because they can be selected without separator chars, but I anticipate that I will be able to get to all of them with the unix separator patch. But if Apple had been able to read an RFC, none of it would be necessary at all.
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Nick Sayer wrote: > > > I am pleased to announce the availability of a selectable hierarchy > > separator for Cyrus IMAP. Up until now, Cyrus used a netnews-style > > hierarchy, where '.' was used as the hierarchy delimiter -- thus > > prohibiting '.' from appearing in mailbox names. This release allows a > > UNIX-style '/' separator to be used in the same fashion that David > > Fuchs' (and derivative) patches. > > Hey great! This will let me work around MacOS X's Mail program's stupidity > in this regard. Before I set up alt namespace, I couldn't get to any of my > folders besides the INBOX! Doesn't anyone read an RFC anymore before they > write software? Sheesh. Who? Me or the Mac guys? Are you saying that the server doesn't display them or allow access to them, or that your client can't deal with the namespace/hier-sep change? Do this to see what the server is doing: 1. either telnet to the server and login, or connect with imtest 2. enter: a NAMESPACE 3. enter: b LIST "" * 4. enter: c LOGOUT This will show you the namespace and all folders that you have access to. If what gets returned is incorrect, please let me know. Otherwise, try refreshing the folder list in your client, or setup a different profile. 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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
> I am pleased to announce the availability of a selectable hierarchy > separator for Cyrus IMAP. Up until now, Cyrus used a netnews-style > hierarchy, where '.' was used as the hierarchy delimiter -- thus > prohibiting '.' from appearing in mailbox names. This release allows a > UNIX-style '/' separator to be used in the same fashion that David > Fuchs' (and derivative) patches. Hey great! This will let me work around MacOS X's Mail program's stupidity in this regard. Before I set up alt namespace, I couldn't get to any of my folders besides the INBOX! Doesn't anyone read an RFC anymore before they write software? Sheesh.
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Oops! Due to a small oversight (and not checking the tar.gz) on my part, the distribution that I created was essentially just an alt-namespace distro. I have repackaged the correct code and uploaded it to the URLs below. If you have already downloaded the code, please grab it again. Note: If you use CVS, this does NOT affect you. Sorry any inconvenience, Ken Ken Murchison wrote: > > I am pleased to announce the availability of a selectable hierarchy > separator for Cyrus IMAP. Up until now, Cyrus used a netnews-style > hierarchy, where '.' was used as the hierarchy delimiter -- thus > prohibiting '.' from appearing in mailbox names. This release allows a > UNIX-style '/' separator to be used in the same fashion that David > Fuchs' (and derivative) patches. > > This code leverages my previous alt-namespace work, and as a result does > NOT change the on-disk mailstore structure, only what is sent via the > IMAP protocol. This means that any existing server can begin serving up > mailboxes using the UNIX hierarchy separator (and/or the alternate > namespace) simply changing the appropriate imapd.conf option. In order > to maintain compatibility with the on-disk structure, '.' in mailbox > names are translated to '^' before being saved to disk. > > You should consider this code to be alpha, but it is fully functional > and appears to be as stable as the alt-namespace code. I hacked this > code in a couple of hours mainly as a proof of concept, so incompatible > changes (such as the use of '^') may be made in the future, ie, DO NOT > run this on a production server just yet. I am hoping to have people > test this code for bugs and performance issues (currently none known) > before I commit to making this part of the standard distribution. > > Configuring the server to use the UNIX hierarchy separator is done by > setting "unixhierarchysep: yes" in imapd.conf. With this option, and > the 'altnamespace' option, there are now four combinations of namespace > and hierarchy delimiter. > > The code can be obtained from CMU's CVS repository as usual using the > 'hier-sep-r1' tag. Otherwise, a pre-packaged distro can be obtained > from: > > ftp://ftp.oceana.com/pub/cyrus-imapd-2.0.14-HIERSEP-r1.tar.gz > http://www.oceana.com/ftp/cyrus-imapd-2.0.14-HIERSEP-r1.tar.gz > > Since I am the primary developer of this code, please send any feedback > to me directly and/or the info-cyrus list. Please do NOT send bug > reports to cyrus-bugs. > > Enjoy, > 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 -- 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
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Date: Fri, 6 Jul 2001 00:40:15 -0400 From: "Kevin J. Menard, Jr." <[EMAIL PROTECTED]> [...] Hmm . . . This would be fine for me, but maybe someone else would run into a problem with wanting to use '/' in a username (have no clue why). In that case, an entry like "usesep: whatever_char_here" might be a better idea, although admittedly harder to implement. Yeah, one could imagine this. However, making it more configurable just means that admins can set it to something stupid; IMAP interoperability is bad enough as it is, and we'd rather not deal with people complaining that they set the hier-sep to "a" and Outlook 95b12 doesn't work. Larry
Re: [ANN] UNIX hierarchy separator for Cyrus IMAP
Hey Ken, Thursday, July 05, 2001, 9:45:04 PM, you wrote: KM> I am pleased to announce the availability of a selectable hierarchy KM> separator for Cyrus IMAP. Up until now, Cyrus used a netnews-style KM> hierarchy, where '.' was used as the hierarchy delimiter -- thus KM> prohibiting '.' from appearing in mailbox names. This release allows a KM> UNIX-style '/' separator to be used in the same fashion that David KM> Fuchs' (and derivative) patches. :) Thanks Ken and Dave. KM> This code leverages my previous alt-namespace work, and as a result does KM> NOT change the on-disk mailstore structure, only what is sent via the KM> IMAP protocol. This means that any existing server can begin serving up KM> mailboxes using the UNIX hierarchy separator (and/or the alternate KM> namespace) simply changing the appropriate imapd.conf option. In order KM> to maintain compatibility with the on-disk structure, '.' in mailbox KM> names are translated to '^' before being saved to disk. I guess you figured it out. Last I knew, you and Larry didn't even know if this would be possible ;) KM> You should consider this code to be alpha, but it is fully functional KM> and appears to be as stable as the alt-namespace code. I hacked this KM> code in a couple of hours mainly as a proof of concept, so incompatible KM> changes (such as the use of '^') may be made in the future, ie, DO NOT KM> run this on a production server just yet. I am hoping to have people KM> test this code for bugs and performance issues (currently none known) KM> before I commit to making this part of the standard distribution. KM> Configuring the server to use the UNIX hierarchy separator is done by KM> setting "unixhierarchysep: yes" in imapd.conf. With this option, and KM> the 'altnamespace' option, there are now four combinations of namespace KM> and hierarchy delimiter. Hmm . . . This would be fine for me, but maybe someone else would run into a problem with wanting to use '/' in a username (have no clue why). In that case, an entry like "usesep: whatever_char_here" might be a better idea, although admittedly harder to implement. KM> The code can be obtained from CMU's CVS repository as usual using the KM> 'hier-sep-r1' tag. Otherwise, a pre-packaged distro can be obtained KM> from: KM> ftp://ftp.oceana.com/pub/cyrus-imapd-2.0.14-HIERSEP-r1.tar.gz KM> http://www.oceana.com/ftp/cyrus-imapd-2.0.14-HIERSEP-r1.tar.gz KM> Since I am the primary developer of this code, please send any feedback KM> to me directly and/or the info-cyrus list. Please do NOT send bug KM> reports to cyrus-bugs. KM> Enjoy, KM> Ken Oh, I will :) Thanks a lot Ken. I've been using Dave's patches quite successfully (thanks Dave), but was looking to see them implemented with your ANN. -- Kevin
