On Thu, 20 Feb 2003, Caskey Dickson wrote: > > a suggestion? > > The maildir++ spec requires that some character be designated the separator. > Any character will do, courier uses '.'.
So for Courier compatibility bincimap should as well. > >>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. > >> 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? > >>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. > 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. > 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/ -- Charlie Brady
