On Thu, 20 Feb 2003, Caskey Dickson wrote: > > > > 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.
You're assuming that there is, and should be, a mapping from maildir name to IMAP name, and that it is the inverse of the IMAP to folder mapping. I don't see the need for one. AFAICT, ./.INBOX can quite happily exist as a folder, but can't be referenced by IMAP. INBOX already is a special case as far as IMAP is concerned. We need to map it to a folder. Then we add an arbitrary collection of folders to that one. I don't see anywhere that there is a defined relationship between these other folders and "INBOX". > 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. It doesn't exist in the IMAP world. I don't think you will lose sleep over that fact. > 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 seems unnecessarily complex. If you feel the need to have what seem to be subfolders of INBOX, just create INBOX.Foo.Bar (or INBOX/Foo/Bar if that is how your IMAP clients see the hierarchy) via your IMAP client, and the imap daemon will call the maildirs ./.INBOX.Foo.Bar according to the standard rules. The only special case needed AFAICT is "INBOX". > 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). Does "peer" have any useful semantics associated with it as you use it here? > > > 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. YMMV, but I've seen . more often used than : in mailbox names. > It isn't even sideways. ? > > > 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... Unarguably. But how often does their IMAP client ask the server to walk the hierarchy. But let's move on. > Users unerringly stick their finger straight into the hole labeled 'do not stick >finger here'. See above re "no folder names containing '.'". :-) > > > 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. Representing a nested structure as a list also seems wrong. But let's move on. > 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. I'm not sure what your metric is, but let's move on. > 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. OK. > Regardless, even ignoring the complexity, the syscall load is a strong > enough argument (I feel) to warrant a flattened representation. OK. > > 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. This is an optimisation, so I hope this won't be touched until we are all happily running bincimap. -- Charlie Brady
