On Thu, 20 Feb 2003, Andreas Aardal Hanssen wrote: > 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.
I don't have a problem with it being a requirement that courier compatibility is possible. I do have a problem with courier compatibility being imposed on every deployment, if it means arbitrary and unnecessary restrictions. But you're building this software, I won't labour the point further. If you must impose a leading period, then so be it. > >- 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. Says who? I don't see at http://cr.yp.to/proto/maildir.html that a maildir may not contain other directories/maildirs. > An _extension_ of Maildir, called > Maildir++, allows subfolders. We can either follow this extension, or > define our own extension. I don't see that an extension definition is necessary. It just "is". > I will not break Maildir++. So be it. > >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. I guess. > >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. Does that mean that one suddenly has multiple root folders if one removes maildirfolder. > >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? Before removing a/b, your directory heirarchy is: a - tmp - new - cur - b - tmp - new - cur - c - tmp - new - cur after removing a/b it is a - tmp - new - cur - b - c - tmp - new - cur So, a directory is a folder if it is a maildir, or a folder marked \NoSelect if it is not a maildir, but contains one or more folders. > 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++ Please add to that list clarification of NAMESPACE and INBOX.* name overlay issues. Thanks -- Charlie
