This particular dual-use patch is not the sort of patch I would intend to be incorporated into UW IMAP, for a number of reasons.
First, it really is a hack. Which means I bullied some code out of the way, everything I've inserted is ifdef-ed, and I changed a spot of code where I'm not aware of the full implications for the IMAP protocol. It's not code that anyone would want to maintain as the surrounding code evolves. Second, both dual-use options in the patch are perversions. For the "shadow mailbox", in the limit of making every folder a dual-use folder, what you get is a bunch of directories, and in each directory, the messages are stored in a ".self" mailbox. That's not very user friendly for direct manipulation. For the "companion dir", you have to properly modify a directory path (by adding, say, "_@dir" to all directories within the mail tree) to access a mailbox. This is not a problem at a shell prompt, because the structure is blindingly obvious, but it could be troublesome for automated scripts. But, the patch does provide some things. First, it shows that different forms of dual-use can be rolled in without stomping over too much code. Second, it does it in such a way that it augments the current, standard mail tree structure; so, mail folders can be made dual-use piecemeal. Third, it sufficiently suits my needs (since I rarely interact with my mail subfolders anywhere except an IMAP client). I think it could suit the needs of others, as well; that's why I've made it available, regardless of its imperfections. For slightly more permanent dual-use features, I believe the best option would be to (only slightly) augment the standard mail tree convention. I've seen arguments that blame the lack of standard support for dual-use on deficiencies in the host file system. Probably a more legitimate explanation is the evolution of the naming convention for mailboxes. Because standard mailboxes started out as just the username in a mail spool directory or ~/INBOX, a standard filename extension didn't work its way in on the ground floor. But, a mail filename extension would not be something entirely unexpected. Users are largely familiar with filenames having a short extension that suggests the file type (.html, .txt, .tar.gz, .jpg, .zip, .ps, etc). Filename extensions allow for different file types with otherwise nearly the same name. So for instance, you don't end up blowing away your source file without a .c extension with its object file without the .o extension. Under those circumstances, you'd be hard pressed to fault the file system. So, create a similar mail tree convention as the current one, but assert that all mail files have a standard extension, say ".mb" for "mailbox". As usual, apply no extension to directory names. In the server, present folders-with-messages with the .mb chopped off and present folders-with-folders as dual-use when appropriate. Then, dual-use falls into place. It also backward compatible with single use interpretation, with the caveat of having to look at all those unsightly .mb's attached to the folder-with-messages names. That setup also doesn't suffer from the perversions in this particular patch. Although the naming between IMAP and the host file system wouldn't be exact, it's something users would otherwise so expect they wouldn't skip a beat when encountering it. And, because the modification is otherwise so simple, it.s not difficult to bring tools that interact with the mailboxes at the file system level up-to-date. As for the single-use/dual-use debate in general, itself is a perverse outgrowth of legitimate optimizations made in the IMAP protocol. In a local file system, users expect folders to be able to contain both subfolders and files. However, to iterate through just the subfolders (to build a folder tree), in the local file system you have to sift through all the files and subfolders together. So I assume since requesting a folder tree via IMAP is such a common operation, the IMAP protocol directly supports listing the just subfolders without all the numerous message headers. Because this optimization happened to so nicely coincide with deficiencies in the naming convention of mail folders, we have "single-use". I'm not going to even get into the "single open command" issue. It's nonsense. Rarely is the exclusion of features in the server justified by deficiencies in the interface of the client. All of that aside, I think UW IMAP is good stuff. That's why I made my patch for it, because I wanted to continue using it. Cory Sharp
