Hi, Volker. :-)
On Wed, 25 Feb 2004, Volker Sauer wrote:
>after migarting to bincimap, there are some little things left open:
>6. I tried to use ImapDir which I set up in binimap.conf, but Mozilla
>1.6 and Thunderbird 1.5 didn't like that. Folders like
>"~/MailDir/PrivatMail/MyGirlFriend" didn't appear in the "Manage folder
>subscriptions" menu. So I used "PrivateMail.MyGirlFriend" and the menu
>provied the correct tree-structure. Is this a problem of the
>Mozilla-project?
>I can live with that, but it would be nicer to have subdirectories in
>ImapDir-Style, because the tree in my mailbox contains more than 200
>leafes wich makes ~/MailDir a little complex.
I think I understand what you're saying; please correct me if I'm wrong.
Both the Maildir++ and IMAPdir depot use a single level of subfolders
inside the depository root directory (such as Maildir/).
The reason for this is that IMAP has special rules for subdirectories that
don't make sense in a standard UNIX VFS environment, and the chosen
structure replicates this behavior most naturally.
For example, the directory A/B can exist even though A doesn't. If you
have the two directories A, A/B and A/B/C, then deleting A should not
delete all submailboxes too. With the current structure of the depot, this
behavior follows naturally, as A, A/B and A/B/C are three seperate entries
in the directory (A, A.B and A.B.C). Little logic, and simple code.
Having 250 leaf nodes does make this look bad in the file system when
listed with "ls", and it's only natural that one would want IMAP
subfolders to map directly to UNIX subfolders.. but they are basically
speaking not the same thing.
It doesn't make things easier that the Maildir mailbox format is
represented as a directory, but other mailbox formats are represented as
files. The way it is done today, the directory entry itself is either a
mailbox, or not a mailbox. If we were to mimic IMAP behavior of multilevel
mailboxes, then we would have to separate the concept of "directory" from
"mailbox". If one user has a Pine mbx mailbox "mymailbox" at the root
level, then this would naturally map to a file:
Maildir/mymailbox (file)
If someone now creates a subfolder of mymailbox, then suddenly mymailbox
needs to be a directory. This means that "mymailbox" can not originally be
a file, it must initally be a directory _containing_ a file. So something
like this, perhaps:
Maildir/mymailbox (dir)
Maildir/mymailbox/mailboxdata (file)
Now comes the problem of somebody creating a mailbox called "subbox"
inside mymailbox. This would also have to be a directory, and let's say
"subbox" is a Maildir:
Maildir/mymailbox (dir)
Maildir/mymailbox/mailboxdata (file)
Maildir/mymailbox/subbox/mailboxdata/{cur,new,tmp}
It has to be this way, because if not, then we would prevent people from
creating submailboxes of "subbox", unless these were created _inside_ the
Maildir "mailboxdata", but this would then be a special case for Maildir
which doesn't work for file-based mailbox formats such as mbx.
So to conclude - it is possible to create a structure like this, but it
requires more logics in the server, and I'm not quite sure if this
alternate folder structure would please admins. The major difference
between IMAP folders and UNIX folders is that the folder itself can both
be a "file" _and_ contain subfolders, and also the feature of
non-recursive deletion.
>8. A further question:
>- how abount shared folders in the future?
Skipping this, see Peter's answer.
>- how about quota in the future?
Quota support is on the list of 1.3 features, and "maildirsize" is on the
list of requested features.
>So far, thanks for your help and for providing such a nice piece of
>quality software!
By all means, happy users are what fuel this project!
Andy :-)
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | "It is better not to do something
http://www.bincimap.org/ | than to do it poorly."
