Re: [bincimap] Folder names

[Caskey Dickson]

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.

Then I guess you need to answer the policy question: is maildir++ the standard that Binc will use to store subfolders of a maildir?

So our discussion sums up to these points:

1) Binc should allow root level folders, next to INBOX

We have two solutions here. One is the NAMESPACE extension, which some clients implement. I like the idea of the NAMESPACE extension, although I think it's a workaround for an implementation problem in a server, and it expects something from the client to "clean it up".

This, I think, is an artifact of the way courier tries to force clients to help manage its storage. Namespaces are good and the extension just points out the fact that prior to the extension clients had no way of knowing where else they could LIST to get interesting stuff, and servers would be foolhardy to list everything in #news and #public when someone does a LIST "" * because what they really (usually) mean is LIST "#personal" *.

NAMESPACE is in many clients a configurable setting that does not require
a server extension. In Outlook you can set "INBOX." as the path to the
root folder, and Outlook will do some magic to flatten the folder tree.

This will not allow subfolders of INBOX next to root folders, though.

The other alternative is to implement this in the server. This might mean
that users would not be allowed to create folders under INBOX, but we
could do something smart here, like creating a special folder under
Maildir/ that conforms to Maildir++ and is interpreted as the root folder
in Binc IMAP, but as a subfolder of "folders" in other clients.

That's an idea. But like any 'magic' data, it runs into the problem of what to do when someone wants to name a folder that magic folder name. (Thus the use of a magic and unlikely-to-be-used character '#' to escape a 'namespace'.)

One thing BincIMAP should do is ensure that if/when it decides to implement NAMESPACE, it uses something less confusing than INBOX as the personal namespace prefix.

 2) Binc should allow any hierarchy seperator, and should store
    folders different from what it does today.

Binc will allow any hierarchy seperator, but the same seperator will be
used inside the Maildir. The first character must FWICS be a '.' for
Maildir++ to accept it as a subfolder, and all folders must be called
Maildir/.a/ and Maildir/.a.b/, not Maildir/.a/.b/.

I agree that a configurable heirarchy separator would be a good idea, the IMAP
protocol allows it. As for storage, I think that beginning the local store, with the separator makes an easy way to designate that INBOX is the intended
super-folder without having to place mail outside of the Maildir/.

This breaks the UNIX standard that dotted files are hidden, and as much as
I hate it, I would rather create a completely new format than break the
existing *ehem* "standard".

We could design a Maildir^=2 or something. ;)

That's an option. I'm certainly no fan of maildir++, nor do I know of any clients (and client like things) that make use of it other than maildirquota, Courier and Dovecot. Note that even the path separator is unspecified in maildir++ so it's a weak standard at best.

I'd like to recommend ':'. Does anyone have an objection to using colon as the storage-separator? With Maildir/:foo Maildir/foo and Maildir/foo:bar representing INBOX.foo, foo and foo.bar respectively? (Or in namespace-format #personal.INBOX.foo, #personal.foo and #personal.foo.bar.)

C=)

--
--------------------------------------------------------------------------
Better the hard truth than the comforting fantasy. -- Carl Sagan
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
A presumption on your part does not constitute an obligation on my part.