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

