Re: [lee@piclab.com: Re: [bincimap] Folder names]

[Caskey Dickson]

Andreas Aardal Hanssen wrote:

Some users find it unnatural that all folders must be created as
subfolders of INBOX, even though it's perfectly logical why it's like that
from a technical point of view. If we are to allow creating folders on the
root level, next to inbox, we may do the following. Selecting INBOX will
be the same as before, but selecting a folder called "a" will select

~user/Maildir/.a/

Similarily, creating "foo" will give

~user/Maildir/.foo/

I think we're in agreement, but I'd recommend that selecting 'a' gives
~user/Maildir/a and selecting 'INBOX.a' gives '~user/Maildir/.a'. This scheme allows for both simultaneously and in a straightforward manner.

Since we can not tell wether the user meant that Maildir/.foo/ should be
interpreted as INBOX.foo or simply as foo, we need to choose one. I would
like the choice to be that "foo" implies ~user/Maildir/.foo. Creating
folders as subfolders of INBOX has no technically simple solution if we
follow the '.' convention. I'm not able at this time to say wether this is
the only standard way to represent folders in Maildir.

For clients that use the current policy of subfolders-under-INBOX, they
must still be allowed to select their old INBOX.a folders, but they are no
longer allowed to create new ones there. If they reset their subscription
list, they will see that their old "INBOX.Sent_Mail.2002.Feb.23" folder is
now called "Sent_Mail.2002.Feb.23", that is - on the root level, not under
INBOX.

But I see what you mean - that we could allow both. The question is - can
we allow both in such a way that any Maildir client (not necessarily Binc
IMAP client) would understand the Maildir structure?

Moving people's folders is a bad idea, especially when people use multiple clients. As for how people prefer to manage their folders, I think that such issues are between them and their client, the server should support all modes in a manner most conducive to administrators and MTAs. (Frankly I'm delighted at the prospect of BincIMAP supporting folders properly.)

users to a format where no subfolders are allowed under INBOX unless they
are there "already".

Is there a reason to prevent folders under INBOX? The standard doesn't seem to limit such things. If so, why? If not, then I say leave them.

The reason for preventing this is that many users find it logical to
create folders next to INBOX and not inside INBOX. I think it's ok to
create them inside INBOX (heck, anywhere!) but many don't.

Well, the server should allow what the standard allows, and users should use a client that supports their mental 'scheme' for how email should be organized. But, I think we're heading in this direction already.

I suppose my question is this: Is bincimap currently translating selects on "a" to "INBOX.a"? If so, this behavior should be deprecated. If not, then

No, it is not. Selecting "a" today is not allowed.

Excellent!  Then we are already poised for allowing root-level folders.

simply allowing a means to create and maintain root folders--and designating them, perhaps without a leading '.' would be the best solution. Subfolders of Maildir/ that are detected as Maildirs are offered up as either subfolders of INBOX if the beign with '.' or as their own top-level folders if they do not.

I see your point. We could allow both root level folders and INBOX
subfolders. I'll have to investigate the Maildir subfolder extensions to
see if this is allowed.

>

In this case, let the authenticator return the full path, and set the
mailbox path in the Binc config to "", the empty string, and report it as
a bug if it doesn't work. :-)

This is what we are doing, my point was that if the solution to root folders expects to be able to create Mail/foo next to Maildir/, then it will break the creation of IMAP toasters.

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.