Re: [bincimap] Maildir++

[Caskey Dickson]

Charlie Brady wrote:

On Thu, 20 Feb 2003, Lee Daniel Crocker wrote:

As the standard says, we can't do a normal directory tree

Does it say why? Most "standards" we use have been RFCs, where we can ask such questions.

It doesn't provide a justification, it just says:

   "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."

we
have to emulate it.  So, taking their suggestion of using ":",

Again, why? Is the ":" enforced by any of the applications, or is it just a suggestion?

The maildir++ spec requires that some character be designated the separator. Any character will do, courier uses '.'.

Bar			-->	./.Bar
Foo.Bar			--> 	./.Foo:Bar
Foo.Bar.Baz		-->	./.Foo:Bar:Baz
INBOX.Foo		-->	./.:Foo
INBOX.Foo.Bar		-->	./.:Foo:Bar

Why aren't the latter two ./.INBOX:Foo and ./.INBOX:Foo:Bar?

Beats me. As long as we check for the special case of ./.INBOX existing and handle it properly your scheme works fine. This will have the effect of moving all existing Courier-style folders up to the root and force any clients to rebuild their local folders--a perhaps painful but necessary operation.

The only thing we've potentially lost is
the ability to use ":" in folder names.  I can live with that.

Can all your users for all time? And do they need to?

Currently they're living without '.', and maildir++ requires that one character be reserved for a separator without any means to escape it.

The best folder heirarchy delimiter to use would seem to be something that the user will recognise as a heirarchy delimiter. '/' works for me.

You can't have '/' in a file name.

Building the list becomes relatively simple: all folders are
in the same directory, so no recursive traversal is necessary.
Just load up the list, sort, and list.  As you list, if you
encounter ".Foo.Bar", and had not listed ".Foo" (which would
have sorted earlier if it were present), you know at that
point that you have to list "Foo (\NoSelect)".  Still no
recursion needed.

Recursion isn't *that* difficult.

No, but it is slow requiring multiple opendir(3), readdir(3), closedir(3) calls, each with three stats, as opposed to a single set and a host of stat's.

Also, the semantics of 'no cur/new/tmp, not a folder' is far more complicated of a check than what maildir++ contemplates. Remeber IMAP requires that a minimum idle time of 30 minutes be supported, it is designed for online idle operation and if you have a mail server supporting hundreds or thousands of users, every system call is amplified many, many times.

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.