91 lines
4.2 KiB
Plaintext
91 lines
4.2 KiB
Plaintext
MBOX-Line: From bhayden at umn.edu Wed Dec 30 04:57:28 2009
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brian Hayden <bhayden@umn.edu>
|
|
Date: Fri Jun 8 12:34:43 2018
|
|
Subject: [Imap-protocol] Childless noselect mailboxes
|
|
In-Reply-To: <alpine.DEB.2.00.0912300000110.22394@Higashi-Tomobiki>
|
|
References: <1262106049.26478.745.camel@timo-desktop>
|
|
<alpine.OSX.2.00.0912290938230.18442@hsinghsing.panda.com>
|
|
<1262111858.26478.842.camel@timo-desktop>
|
|
<alpine.OSX.2.00.0912291042070.18442@hsinghsing.panda.com>
|
|
<1262114250.26478.864.camel@timo-desktop>
|
|
<alpine.DEB.2.00.0912300000110.22394@Higashi-Tomobiki>
|
|
Message-ID: <Gophermail.2.0.0912300657280.23421@vs-w.tc.umn.edu>
|
|
|
|
On Dec 30 2009, Mark Crispin wrote:
|
|
|
|
>On Tue, 29 Dec 2009, Brian Hayden wrote:
|
|
>> Sorry if I was unclear. As noted I wasn't talking about the creation
|
|
>> action,
|
|
>> but the concept of \NoSelect itself.
|
|
>
|
|
>A \NoSelect object is a directory.
|
|
>
|
|
>Select is the operation to open a mailbox.
|
|
>
|
|
>> A directory in Windows, OS X, or most of the Linux desktop environments
|
|
>> (for
|
|
>> example) is "selectable", both conceptually and in IMAP terms--because
|
|
>> it is
|
|
>> "dual-use".
|
|
>
|
|
>Nonsense. I can not execute a directory on Windows, OS X, or Linux. Nor
|
|
>can I edit it in my editor. The only thing that can be done in a
|
|
>directory is access its children.
|
|
|
|
"Nonsense" is a very strong word (and yes, you certainly can edit a
|
|
Linux/Unix directory in a text editor, for most flavors of Linux/Unix).
|
|
Suffice to say I've spent thousands of hours on this with average users, a
|
|
lot of them in usability labs, and this is not how a user thinks about it.
|
|
What they say over and over again is: "How come these folders can only
|
|
contain folders? In Windows my folders have folders and files." They see a
|
|
file as analogous to a mail message, not a mailbox. And if you stop for a
|
|
second to think about it, it's obvious why--a file and a mail message both
|
|
contain text data. Because they equate those two, they naturally equate
|
|
their containers.
|
|
|
|
>A mailbox is not a directory. It is an object containing messages, just
|
|
>like a text file is an object containing paragraphs of text.
|
|
|
|
Obviously, and irrelevant. I'm not talking about what we know about IMAP,
|
|
I'm talking about how users see things (and thus, what might be the most
|
|
productive way to present these things in a client).
|
|
|
|
>A text file doesn't contain other files, nor does it contain executable
|
|
>programs. It is single use, just as a directory is.
|
|
|
|
Only in the most literal sense. Really, it is single use *just as a message
|
|
is*. A directory does not contain paragraphs that a person reads. I'm not
|
|
talking about ontology here, I'm talking about how a user perceives it.
|
|
|
|
>A message is not an object in the named hierarchy tree. It is a piece of
|
|
>an object in the named hierarchy tree. The fact that some clients pretend
|
|
>that a message is something else doesn't change what it actually is.
|
|
|
|
I think you make a mistake here to assert that "some" (all) clients are
|
|
somehow wrong to present it that way, when it's done that way because the
|
|
message is the fundamental object that users care about. They don't care
|
|
that in the IMAP protocol it is a piece of an object. Nobody prints a
|
|
mailbox and pins it on their bulletin board. They print a message.
|
|
|
|
>Only IMAP has these bizarre "dual use" objects, and only because some
|
|
>people insisted upon it and I failed to say "no" when I should have.
|
|
|
|
I think that's inaccurate. It's technically correct from an "action"
|
|
perspective--yes, the only thing you can do with a directory in a
|
|
filesystem is access its children (not really, but close enough)--it isn't
|
|
true from the object model perspective. Filesystem directories contain both
|
|
, at a more fundamental level users are used to a "folder" (filesystem
|
|
directory) containing both other "folders" and "files". I am intimately
|
|
familiar with everything you wrote here but it has no bearing on the
|
|
concerns of a user. Your initial assertion was "crappy clients display
|
|
\NoSelect mailboxes badly". My contention is that, while most of the
|
|
clients are crappy, ALL clients handle \NoSelect badly because it's not a
|
|
familiar concept--and nobody has tried to come up with a solid way to
|
|
present it to the user.
|
|
|
|
Thanks for your thoughtful reply.
|
|
|
|
-Brian
|
|
|