Hi, Charlie. On Mon, 17 Mar 2003, Charlie Brady wrote: >On Mon, 17 Mar 2003, Andreas Aardal Hanssen wrote: >Please don't go there. >We need to decide what we are doing and why we are doing it.
The first couple of lines of the IMAPdir draft state what we are trying to do. Other than that, the goal of this specification is to find a way to store multi level IMAP mailboxes on a file system in an unambiguous way. >On the one hand, we have the IMAP view of the world. We can either use / >or . as the hierarchy separator. Either way works: >foo >foo/bar >foo/bar/ >boo/bar/baz >or >foo >foo.bar >foo.bar. >foo.bar.baz Absolutely. Every server is free to choose a delimiter. However, the IMAPdir specification suggests (perhaps suggests is too loose) the seperators / or \, and that's no coincidence. / and \ are natural delimiters in a folder hierarchy, and everyone's used to it. '.' is not a delimiter, it's just a character that is allowed in any file name. Now most shells allow escaped characters too. The '.' comes, from what I understand, from NNTP. The news protocol exports its news groups list using '.' as the delimiter, probably an artifact from older days when having '/' in a file name was considered a problem. There is no reason for other protocols not to export '/' or '\' as the delimiter. >and presumably we can also allow a leading (null) separator. >The next thing we need to do is to map these folders into file system >Maildirs. Obviously the mapping must be ambiguous. >My preference is to use the natural mapping >foo => $prefix/foo >foo/bar => $prefix/foo/bar >foo/bar/ => $prefix/foo/bar >boo/bar/baz => $prefix/foo/bar/baz If you read one of my previous mails on this list, you will see that this approach does not work very well. You need to consider the facts of UIDVALIDITY with delete and rename (renaming a superior also means that inferiors should be renamed, taking UIDVALIDITY values into consideration), deleting a superior does not imply deleting its inferiors and that this approach would need a recursive descent traversal while the one suggested by Maildir++ and IMAPdir does not. This approach also fails for mailbox formats other than Maildir or other directory based formats. You can not create the same structure using, say, mbox. >We start getting ourselves, and probably others, confused if we try to >allow either . or / to be used as part of a folder name. The only simple To this I do not agree. If '.' is not the hierarchy delimiter, then there is no reason to disallow its use in mailbox names. With '/'. If someone wants to make a mailbox called "Before/after year 2000" Then this should naturally be allowed when a '.' is the delimiter. Likewise, "2nd. world war" should be allowed when '/' is the delimiter. Not only does this have an easy logical implementation, but it is makes sense to users too. The only character that is not allowed is the hierarchy delimiter. >such case is if we are using / as the hierarchy separator, and we are >not using . in the filesystem to separate components (i.e we have the >first case above, and are using subdirectories for subfolders). >To put that another way: > If we use . as the hierarchy separator, we must declare / as an illegal > character in folder names. > If we use / as the hierarchy separator, and we emulate a folder tree > after Courier, then we must declare . as an illegal character in folder > names. I agree to the first but not the second. What you seem to mix up here is the mailbox name as presented in IMAP, versus a mailbox name's representation on the file system. We can choose an arbitrary delimiter in IMAP and in the file system, independent of eachother. Typically, the file system representation will be an encoding of the name as presented in IMAP. The reason for the exception with the single dot at the start of a mailbox name is to allow Maildir++ users to convert painlessly. The side effect for Maildir++ users is that they can not have a root level folder named "cur", "new" or "tmp" containing mails. They will have to live with this until the admin converts their depositories to true IMAPdir. >OTOH, we have a file and directory hierarchy, and we wish to export a >subset of it by IMAP. There is no requirement that I can see that all >files and directories can be referred to via an IMAP folder name. Don't >invent that requirement. This you will have to explain to me. The representation of the mailbox name _must_ map one to one with the name of the mailbox as exported by this structure. In that sense, yes - in IMAPdir you _must_ be able to refer to each mailbox name's file representation with an IMAP mailbox. >I personally have a requirement for bincimap to export a set of folders >currently managed by a maildir patched UW-imapd. I am satisfied that I can >move and rename directories as I need to when the time comes to convert >systems. Nevertheless it would be nice to be able to export the current >folders as-is, with no migration. If we are to represent the structure of all formats exactly the way that individual clients represent them to their users, then we will never get anywhere. The file system says something about the structure to an IMAPdir compliant client. This client must be required to represent this structure exactly the way IMAPdir defines it, to the client. How the client then represents the IMAP server's structure to its user it of utter irrelevance for this discussion. >> So this would be the exception: either one or two dots at the start of an >> item in IMAPdir represents one dot in the start of the mailbox name: >> .foo -> .foo >> ..foo -> .foo >> How does that sound? >Bad :-) I have a refinement. A single dot at the start of a filename refers to a single dot at the start of an IMAP mailbox. Anywhere else in the file name, two consecutive dots represent a single dot and a single dot represents the hierarchy seperator/delimiter. .foo -> .foo ..foo -> ./foo .foo..bar -> .foo.bar .foo.bar -> .foo/bar So: July 2nd.. -> July 2nd. July.2nd -> July/2nd This is completely unambiguous. Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
