On Apr 18, 2008, at 11:42 AM, Mark Crispin wrote:
On Fri, 18 Apr 2008, Michael Cashwell wrote:
I must be being dense here, but isn't having an inferior to INBOX
named identically but with only case differences a very special
case? Wouldn't it make more sense to prohibit only that similar to
how a case-preserving but case-insensitive file system won't let
you create "foo" where "Foo" already exists?
The problem is not with the children, but rather the parent. You
are assuming, falsely, that there is something magic that will take
"inbox/foo" and know that it really must be "INBOX/foo" even though
there is nothing in the IMAP specification (or most UNIX
filesystems) that says so.
But that's what I'm not getting. Doesn't it map "inbox" to "INBOX" as
a special case already? If not, then "inbox/foo" should fail. If so,
why is mapping "inbox/foo" to "INBOX/foo" worse?
Even if imapd attempted to impose such magic, there is nothing that
it can do about filesystem operations outside of IMAP. That is the
underlying cause of the problem.
Do you mean other apps that use c-client or apps that fiddle with the
backing store totally on their own?
If the latter then they deserve what they get. If the former then is
the problem expecting (or inserting) IMAP semantics when IMAP is not
really involved? I could see that being a mistake.
I'm fuzzy on the division of labor between c-client and imapd. I had
assumed that some IMAP-isms like the InBoX -> INBOX morph occurred in
the c-client code.
Having inferiors to INBOX called anything else would not be
ambiguous, right? To prohibit ALL inferiors on INBOX just to avoid
this one instance of case-ambiguity seems like overkill.
That's like saying it is overkill to have laws against drunk
driving, because you can drive safely while drunk. Even if that is
true in your particular case, it is not true in the general case.
I think that's 180 degrees around. Outlawing all inferiors of INBOX
because of one very particular ambiguous case is like outlawing all
drinking because some people drive drunk.
It is never a good idea to create greater complexity to overcome the
problems brought about by adding earlier complexity.
Certainly agree. But in this case, from the user perspective, the
complexity is the inbox being "special" for some mysterious reason.
IMAP was never intended to allow children of INBOX. In fact, IMAP
was never intended to allow children of any mailbox. It was a
terrible mistake to have allowed dual-use mailboxes in the
specification in the first place.
I can accept the idea that if the IMAP spec was written without taking
dual-use mailboxes (those that logically hold both messages and other
mailboxes) into account that it may well be a bad idea to try to
kludge that in after the fact. Kludges are bad.
But consider a very similar case: files stored in a file system. A
dual use prohibition there would mean files could only exist as leaves
of the hierarchy with no files and directories as peers. That would be
a wildly artificial and unpopular limitation.
It surprises me that with the dual-use file systems metaphor so well
established that the IMAP spec would have been originally written with
the assumption that users wouldn't want the same metaphor in their
mail stores.
-Mike
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
