Hi, Gary. :-)
On Wed, 19 Mar 2003, GARY GENDEL wrote:
Andreas Aardal Hanssen wrote: <snip>
If foo is an mbox, foo/bar is a maildir and foo/bar/foo is an mbox, how would you represent this structure with your suggested scheme?
I'm fairly new to this conversation and I'm confused by this example. How can foo be both an mbox and a maildir, or is this the crux of the problem? If I understand it correctly, you want to represent hierarchy via two differing mechanisms; one for mbox (flat) and one for maildir (hierarchical). The problem then is how to resolve the namespace mapping into a single namespace.
We are mapping all mailbox formats in which one mailbox can be identified by a file name or directory (link), into the same hierarchical structure using a soft hierarchy delimiter '.'.
So wether the mailbox is a Maildir or an mbox should not make any difference. If we use the name of the mbox and Maildir to both denote the mailbox' name and location in the hierarchy, then there is no need to differ between the two.
Agreed.
In my opinion, utilizing the fact that a Maildir is a directory based format, to provide a file system based hierarchy is wrong, because that means that if foo is a Maildir:
foo/
And foo/bar is an mbox, that is - inside the Maildir directory:
foo/bar
I think I didn't explain clearly my idea. In my proposed scheme:
Maildir foo would be a directory called "foo" with the required new, curr, and tmp directories for Maildir handling.
Mailbox foo/bar would be an mbox named anything you want, anywhere you want, but it would be referenced by a link in the directory "foo/bar" by a soft or hard link called mbox.
Below is an illustration of what you described in my scheme. I took the liberty of adding a directory called "flat" to put the mbox files, but the only restriction is that the mbox files not be placed in the directory tree used by my Maildir extension proposal.
flat (directory) | |-- foo.bar (mbox file)
foo (directory) | |-- bar (directory) | | | |-- mbox (link to mbox file flat/foo.bar) | |-- new (directory) |-- tmp (directory) |-- cur (directory)
And you delete foo, perhaps by removing the new/tmp/cur directories inside foo/ and leave the directory itself:
foo/bar
Ok, now there is this:
foo (directory)
|
|-- bar (directory)
|
|-- mbox (link to mbox file flat/foo.bar)then create a mailbox called "foo" which is an mbox, then you have a problem. The link "foo" is already occupied by a directory. This problem is completely solved if the original Maildir "foo" is called
foo/
The mbox mailbox at second level is called:
foo.bar
As does my approach as follows:
flat (directory) | |-- foo.bar (mbox file) |-- foo
foo (directory) | |-- bar (directory) | | | |-- mbox (link to mbox file flat/foo.bar) | |-- mbox (link to mbox file flat/foo)
Note - it's in the same directory, not inside foo/. So you have:
foo/ | Maildir foo.bar | mbox
Removing foo/ is now a logical operation, leaving only:
foo.bar
As is my approach. Deleting foo leave us:
foo (directory)
|
|-- bar (directory)
|
|-- mbox (link to mbox file flat/foo.bar)I just wanted to throw a different approach into the discussion. I'm not saying it doesn't have it's own set of problems, but from a consistency standpoint it makes sense (at least to me). The code can be portable between systems that have native file linking (aka Unix-like), but a substitute mechanism can be made for systems that don't. For example: cygwin on windows does links by adding special header followed by the file name to link in the "link" file. It also makes the name search mechanism quite a bit simpler than the overloading of the '.' symbol as a delimiter. Basically there is only system file naming restrictions imposed, no additional constraints are added.
This is a very interesting discussion and I like see where the holes in my approach are.
Gary
