On Thu, Feb 20, 2003 at 03:14:27PM -0500, Charlie Brady wrote: > > Any character will do, courier uses '.'. > > So for Courier compatibility bincimap should as well.
That would be my general line of thinking. > > >>Bar --> ./.Bar > > >>Foo.Bar --> ./.Foo:Bar > > >>Foo.Bar.Baz --> ./.Foo:Bar:Baz > > >>INBOX.Foo --> ./.:Foo > > >>INBOX.Foo.Bar --> ./.:Foo:Bar > > > > > > Why aren't the latter two ./.INBOX:Foo and ./.INBOX:Foo:Bar? > > > > Beats me. As long as we check for the special case of ./.INBOX existing and > > handle it properly your scheme works fine. > > I don't understand your point about ./.INBOX existing. If ./.INBOX:Foo means INBOX/Foo, then ./.INBOX means INBOX, but INBOX is ./ so you either treat subfolders of INBOX as a special case or you treat .INBOX as a special case. My thinking is that with the former scheme you have a meaningful interpretation of any on-disk structure you find (even those created by silly user programs), while with the latter, a program very well could come along and create a ./.INBOX, and you are left with the question of what to do with it. Here's my recommendation: Simply keep the dot prefix and dot separator as it already is the current behavior and is compatible with Courier. Use dot-dot as the 'INBOX-peer' prefix, relying upon the directory convention to help convey meaning. Thus the examples above become: ./..Bar Peer of INBOX (../Bar) ./..Foo.Bar Peer of INBOX (../Foo...) ./..Foo.Bar.Baz Peer of INBOX (../Foo...) ./.Foo Subfolder of INBOX (./Foo...) ./.Foo.Bar Subfolder of INBOX (./Foo...) This jives nicely with the . and .. semantics of directory names, meaning 'place this folder 'here' (a subfolder of INBOX), and place this folder 'up one level' (a peer of INBOX). > > >> The only thing we've potentially lost is > > >>the ability to use ":" in folder names. I can live with that. > > > > > > Can all your users for all time? And do they need to? > > > > Currently they're living without '.' > > Happily? Beats me, but giving it to them and simultaneously taking away ':' doesn't seem like a step in the right direction. It isn't even sideways. > > >>Building the list becomes relatively simple: all folders are > > >>in the same directory, so no recursive traversal is necessary. > > >>Just load up the list, sort, and list. As you list, if you > > >>encounter ".Foo.Bar", and had not listed ".Foo" (which would > > >>have sorted earlier if it were present), you know at that > > >>point that you have to list "Foo (\NoSelect)". Still no > > >>recursion needed. > > > > > > Recursion isn't *that* difficult. > > > > No, but it is slow requiring multiple opendir(3), readdir(3), closedir(3) > > calls, each with three stats, as opposed to a single set and a host of stat's. > > True, but one doesn't very often build lists of deeply nested folders. It's not the depth, it's their very existence that is the problem. Three system calls per folder, minimum. Besides, one would like to minimize the number of assumptions one makes about the way the user is going to use something. I know of users that have very deeply nested folders. Category/Correspondent/Subject/year/month... Users unerringly stick their finger straight into the hole labeled 'do not stick finger here'. > > Also, the semantics of 'no cur/new/tmp, not a folder' is far more complicated > > of a check than what maildir++ contemplates. > > Sure, but it's not that complicated that it can't be got right. I firmly believe that simple = fast = correct. If something appears complicated or unwieldy, it usually means there's something wrong with it, perhaps even at a fundamental level. I think we will never see eye to eye on this complexity matter as I consider the difference between a flat emulated maildir heirarchy and a true file system heirarchy to be an order of magnitude apart--especially because the maildirness of something is based upon other members of the heirarchy. Each has their complications, but the complexity of the former is contained within the application while the latter's complexity extends into interactions with the operating system in a recursive fashion. Regardless, even ignoring the complexity, the syscall load is a strong enough argument (I feel) to warrant a flattened representation. > > Remeber IMAP requires that a > > minimum idle time of 30 minutes be supported, it is designed for online idle > > operation and if you have a mail server supporting hundreds or thousands of > > users, every system call is amplified many, many times. > > Yes, that's true. Given that we are looking for scalability and > efficiency, will we also consider making use of kernel directory change > notification, if/when it is available? http://oss.sgi.com/projects/fam/ That would certainly be interesting. C=) -- -------------------------------------------------------------------------- Better the hard truth than the comforting fantasy. -- Carl Sagan -------------------------------------------------------------------------- Caskey <caskey*technocage.com> /// TechnoCage Inc. -------------------------------------------------------------------------- A presumption on your part does not constitute an obligation on my part.
