On Thu, 20 Feb 2003, Charlie Brady wrote: >On Thu, 20 Feb 2003, Andreas Aardal Hanssen wrote: >> The problem with not prepending each folder with a dot '.', is that it >> breaks Maildir++. >> http://www.inter7.com/courierimap/README.maildirquota.html >> Although I'm no fan of Courier-IMAP, this is the closest thing we have to >> a Maildir subfolder standard, and we have to conform to it to work well >> together with other Maildir++ applications. >As far as I can tell the leading period is arbitrary and unnecessary.
It's the only standard notation we have. If we change this, then Binc IMAP will no longer be a drop-in replacement for Courier-IMAP. Anyway - who cares what the first character is? The only program that hides '.' files are shells and some unconfigured file explorers. "find" reports them, and "find -d" is the most commonly used UNIX tool for processing directories recursively. I can' see any reason to break Maildir++ just to avoid the leading dot. >- A maildir is a directory containing directories called ""tmp", "new" and > "cur". >- A maildir subfolder is a maildir contained within another maildir. A Maildir has no subfolders, period. An _extension_ of Maildir, called Maildir++, allows subfolders. We can either follow this extension, or define our own extension. I will not break Maildir++. >This maildir++ feature appears unnecessary to me: > Within each subdirectory there's an empty file, maildirfolder. Its > existence tells the mail delivery agent that this Maildir is a really a > folder underneath a parent Maildir++. Agreed, it is quite unnecessary and any sane client would also check for new/, tmp/ and cur/. But being a standard feature means that Binc IMAP will follow it. >[Which mail delivery agents care whether a maildir is a folder underneath >a parent maildir++?] I guess some Maildir++ tools that have the feature to descend into parent directories. >One could argue for this as a useful optimisation - testing for a single >file is quicker than checking for three directories. I'd like to see >benchmarking evidence before accepting that argument. And what use is >the maildirfolder file if "tmp", "new" and "cur" don't exist? The presence of maildirfolder means that this is a subfolder. Lack of maildirfolder means that this is the root folder. >The following seems to be another arbitrary and unnecessary restriction: > Can folders have subfolders, defined in a recursive fashion? The answer > is no. If you want to have a client with a hierarchy of folders, emulate > it. Pick a hierarchy separator character, say ":". Then, folder foo/bar is > subdirectory .foo:bar. >Am I missing something? If you have IMAP folders a, a/b and a/b/c, then remove a/b, then a, a/b and a/b/c should still be visible, but a/b should be marked with \NoSelect. How can this be accomplished if the storage method is that of folders within folders? >Disclaimer: I am not at all advocating breakage of compatibility with >Courier. I am hoping, however, that slavish adherence to that >compatibility is avoidable. Compatibility with standards is absolutely vital this project. Maildir++ may be a lousy standard, it may not even fulfill the requirements to be called a standard yet, but it's all we've got right now. So that's it - we can discuss creating a new mailbox format, creating a new extension to Maildir or we can find ways to accomplish exactly what we want by still complying to Maildir++. I will not have this list flamed by creators of Maildir++ patches to various clients, that are unable to find folders they created with Binc IMAP just because Binc doesn't follow Maildir++. Sticking to the subject - it is completely possible to: 1) make the delimitor configurable 2) display both root folders and INBOX subfolders through Binc 3) be compliant with Maildir++ The question should rather be how we can make this work than in how many ways we can break Maildir++. Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
