mailing list archives

Does anyone think these are actually useful? If server allows creating
"foo/bar" without foo existing, is it actually useful to allow "CREATE
foo/" and have it create a \Noselect "foo" without any children? This
feature is beginning to make some things difficult for me, so I was
planning on removing support for it completely (and actually it's never
been supported by Maildir backend and I haven't heard complaints). Users
also seem to find \Noselect mailboxes in general confusing..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091229/72e3f6bd/attachment.sig>

On Tue, 29 Dec 2009, Timo Sirainen wrote:
> Does anyone think these are actually useful? If server allows creating
> "foo/bar" without foo existing, is it actually useful to allow "CREATE
> foo/" and have it create a \Noselect "foo" without any children?

Are you saying that the only way to do an mkdir MUST be by implicit 
creation, and that if the last child is deleted the superior MUST be 
rmdired?

Note those words "MUST".  They are significant to the argument.

It is perfectly compliant for a server to treat "CREATE foo/" as meaning 
"create a mailbox named foo, and ignore that trailing /".  It is also 
perfectly compliant for a superior to vanish if it is \NoSelect and its 
last child is deleted.

In fact, that is how my new server works.

But that is different from requiring those behaviors.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Tue, 2009-12-29 at 09:54 -0800, Mark Crispin wrote:
> On Tue, 29 Dec 2009, Timo Sirainen wrote:
> > Does anyone think these are actually useful? If server allows creating
> > "foo/bar" without foo existing, is it actually useful to allow "CREATE
> > foo/" and have it create a \Noselect "foo" without any children?
> 
> Are you saying that the only way to do an mkdir MUST be by implicit 
> creation, and that if the last child is deleted the superior MUST be 
> rmdired?
> 
> Note those words "MUST".  They are significant to the argument.

Are you talking about "MUST" as in "what all IMAP servers MUST do"? If
so, no, I'm just talking about what would be acceptable behavior for my
server.

> It is perfectly compliant for a server to treat "CREATE foo/" as meaning 
> "create a mailbox named foo, and ignore that trailing /".  It is also 
> perfectly compliant for a superior to vanish if it is \NoSelect and its 
> last child is deleted.

Or last child is renamed elsewhere. Yes, that's what I was asking about.
Dovecot with Maildir always behaved that way, but now that I'm creating
a new mailbox format I thought I'd get rid of that restriction. But that
in turn seems to be causing more trouble than I thought.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091229/e40a87fb/attachment.sig>

On Tue, 29 Dec 2009, Timo Sirainen wrote:
> Dovecot with Maildir always behaved that way, but now that I'm creating
> a new mailbox format I thought I'd get rid of that restriction. But that
> in turn seems to be causing more trouble than I thought.

What, precisely, is the behavior that you purpose to do in these cases:

[1] "tag CREATE foo/"

[2] "tag DELETE foo" where foo is selectable and has a child?

[3] "tag DELETE foo/bar" where foo is \NoSelect and bar is the only 
child?


The requirements of IMAP in each case:

[1] An object named foo MUST be created, and that object MUST permit 
children.  That object MAY be \NoSelect.

[2] The child of foo MUST NOT be deleted.  The mailbox foo is deleted, and 
the name foo becomes \NoSelect.

[3] The mailbox bar is deleted.


As long as you comply with these requirements, you are fine.  In the [3] 
case, IMAP neither requires nor forbids deletion of foo.  However, common 
sense requires that if [1] creates foo as \NoSelect with no children, then 
[3] should not delete foo.  This is how a server that has "directories" 
would work.

Similarly, if [1] creates foo as a selectable name, I would not be 
surprised if [3] deletes foo.  This is consistent with a server that does 
not have "directories".

It would also be alright if [3] promotes foo to be selectable.


Think of things from the client side.  If the server does not have 
"directories", then the only way that it can have a \NoSelect superior is 
if the client either implicitly created the superior or if the client 
deleted the superior after it got children.  A client which does either 
should be assumed to be intelligent enough to understand IMAP's rules.

The bottom line is that a client MUST NOT expect a server to delete a 
\NoSelect superior automatically, and MUST NOT be surprised if a server 
does so.

If a client wants to keep "empty directories" around, it MUST NOT use the 
implicit creation feature, and MUST NOT delete mailboxes with children 
(if it wants to remove messages, use delete+expunge instead).  Put another 
way, the ONLY way it should make a directory is with the "tag CREATE foo/" 
form.  If that form makes a \NoSelect name, fine; but if it doesn't, then 
don't force it.

I realize that the above is rather complex and probably requires 
re-reading a few times before you fully grasp it.  But I think that if you 
think it through carefully, it'll make sense, seem reasonable, and not be 
all that difficult to implement.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Tue, 2009-12-29 at 11:02 -0800, Mark Crispin wrote:
> On Tue, 29 Dec 2009, Timo Sirainen wrote:
> > Dovecot with Maildir always behaved that way, but now that I'm creating
> > a new mailbox format I thought I'd get rid of that restriction. But that
> > in turn seems to be causing more trouble than I thought.
> 
> What, precisely, is the behavior that you purpose to do in these cases:
> 
> [1] "tag CREATE foo/"

Same as "CREATE foo".

> [2] "tag DELETE foo" where foo is selectable and has a child?

Leave foo as \Noselect, don't delete children.

> [3] "tag DELETE foo/bar" where foo is \NoSelect and bar is the only 
> child?

Delete both foo/bar and foo.

> The requirements of IMAP in each case:
..
> As long as you comply with these requirements, you are fine.  

Right.

> If a client wants to keep "empty directories" around, it MUST NOT use the 
> implicit creation feature, and MUST NOT delete mailboxes with children 
> (if it wants to remove messages, use delete+expunge instead).  Put another 
> way, the ONLY way it should make a directory is with the "tag CREATE foo/" 
> form.  If that form makes a \NoSelect name, fine; but if it doesn't, then 
> don't force it.

I think my main question is: When server supports dual-use mailboxes, is
it a good idea for it to not support creation of \Noselect mailboxes
with "CREATE foo/"? If the server was internally capable of either
creating it as \Noselect or selectable, which one would be better? I
think there are two issues:

1) Technically it's more featureful to create it as \Noselect.

2) Users seem to be confused by \Noselect mailboxes.

I'm beginning to think 2) outweighs 1), especially if there's no good
use case for 1).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091229/a09cc0c0/attachment.sig>

On Tue, 29 Dec 2009, Timo Sirainen wrote:
>> [1] "tag CREATE foo/"
> Same as "CREATE foo".
>> [2] "tag DELETE foo" where foo is selectable and has a child?
> Leave foo as \Noselect, don't delete children.
>> [3] "tag DELETE foo/bar" where foo is \NoSelect and bar is the only
>> child?
> Delete both foo/bar and foo.

These behaviors are all fine.  In fact, this is how my new server behaves.

> I think my main question is: When server supports dual-use mailboxes, is
> it a good idea for it to not support creation of \Noselect mailboxes
> with "CREATE foo/"? If the server was internally capable of either
> creating it as \Noselect or selectable, which one would be better?

If "CREATE foo/" creates a selectable mailbox, I think that a client would 
be surprised if \NoSelect mailboxes without children appear.

> 1) Technically it's more featureful to create it as \Noselect.

I don't think that it's a matter of featurefulness or otherwise.  I think 
that it's a matter of whether or not the server has such a thing as 
directories (\NoSelect mailboxes which can be empty) as opposed to a flat 
namespace that has these funny so-called "hierarchy delimiters" in it.

I think that the worst possible thing would be to create a third 
situation, which is a server which has directories but doesn't create them 
with the explicit "create directory" command ("CREATE foo/").  However, 
that is just my opinion.  The IMAP specification permits it.

> 2) Users seem to be confused by \Noselect mailboxes.

Correction: crappy clients display \NoSelect mailboxes in a confusing way.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Dec 29, 2009, at 2:44 PM, Mark Crispin wrote:
>
> Correction: crappy clients display \NoSelect mailboxes in a  
> confusing way.

Has anyone studied this from a user perspective? I suspect that you'd  
have to come up with an interaction method that is both new and  
intuitive (something that is quite the rare gem) to have the concept  
have any meaning to the user in a client interface -- \NoSelect seems  
quite foreign to everything else they encounter on a computer system  
(or in any other interface, for that matter).

It's possible that every client is crappy, I guess, but in fifteen  
years working on this stuff I've never seen a user that didn't trip  
over it, from Pine to Outlook and everything in between.

-Brian

On Tue, 2009-12-29 at 16:17 -0600, Brian Hayden wrote:
> > Correction: crappy clients display \NoSelect mailboxes in a  
> > confusing way.
> 
> Has anyone studied this from a user perspective? I suspect that you'd  
> have to come up with an interaction method that is both new and  
> intuitive (something that is quite the rare gem) to have the concept  
> have any meaning to the user in a client interface -- \NoSelect seems  
> quite foreign to everything else they encounter on a computer system  
> (or in any other interface, for that matter).

I've never studied, but my personal opinion:

The most annoying thing that a client can do is pop up a message saying
"Mailbox isn't selectable." This is what most clients seem to do.

What I think they should do is (lets assume a GUI client similar to
TB/Outlook/etc):

 - In the window where it would typically show list of messages or
message body, it would show a text something like "This mailbox doesn't
exist, it only contains children." (or something similar to that,
whatever is the most understandable text to user)

 - It could show also a button: "Create this mailbox."

 - It might also show "Child mailboxes:" and have a list of them. This
might be too much.

Hmm. Now that I think of it, I think clients usually show whatever the
NO reply to SELECT is from server. Maybe I could make that a bit more
informative.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091229/2ab2a509/attachment.sig>

On Tue, 29 Dec 2009, Brian Hayden wrote:
> Has anyone studied this from a user perspective? I suspect that you'd have to 
> come up with an interaction method that is both new and intuitive (something 
> that is quite the rare gem) to have the concept have any meaning to the user 
> in a client interface -- \NoSelect seems quite foreign to everything else 
> they encounter on a computer system (or in any other interface, for that 
> matter).

Oh?

The UNIX and Windows shells, with mkdir and rmdir are "quite foreign"?

The Windows Explorer and the Mac OS X Finder are "quite foreign"?

The FTP and SSH protocols are "quite foreign"?

In EVERY other environment besides IMAP, you must create a directory 
before you can put something into it.  In EVERY other environment besides 
IMAP, directories don't vanish when you delete their children.

The ONLY reason why IMAP hides directories under this cloak of "\NoSelect 
names" was to pacify the CMU people who wanted to make everything look 
like NetNews.  Giving in was a HUGE mistake which I have regretted 
enormously ever since.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Tue, 29 Dec 2009, Timo Sirainen wrote:
> The most annoying thing that a client can do is pop up a message saying
> "Mailbox isn't selectable." This is what most clients seem to do.

I agree.  That means that the client listed the mailbox, yet ignored the 
fact that it was \NoSelect.  That's just plain broken client behavior.

> What I think they should do is (lets assume a GUI client similar to
> TB/Outlook/etc):
>
> - In the window where it would typically show list of messages or
> message body, it would show a text something like "This mailbox doesn't
> exist, it only contains children."

Or, it should have separate graphical elements to open as a directory, 
open as a mailbox, or both.  It was much easier when dual-use mailboxes 
weren't the norm, since then the open operation would open in the correct 
mode depending upon the type of object.

Consider how any sort of filesystem browser works.  If you click an 
object, you open that object depending upon what sort of object it is.

Now that dual-use mailboxes are the norm, you need to be a bit more 
creative in the interface.  If everything is icons, you're sort of stuck. 
Either you have two open methods, or you have the object twice, once for 
each of its roles.

With a hierarchy browser, you have a widget to open the children, and 
double click to open the messages.  If you double click a directory, it 
either does nothing or acts as if you clicked the widget.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Dec 29 2009, Mark Crispin wrote:

>On Tue, 29 Dec 2009, Brian Hayden wrote:
>> Has anyone studied this from a user perspective? I suspect that you'd 
>> have to
>> come up with an interaction method that is both new and intuitive 
>> (something
>> that is quite the rare gem) to have the concept have any meaning to the 
>> user
>> in a client interface -- \NoSelect seems quite foreign to everything 
>> else
>> they encounter on a computer system (or in any other interface, for that 
>> matter).
>
>Oh?
>
>The UNIX and Windows shells, with mkdir and rmdir are "quite foreign"?
>
>The Windows Explorer and the Mac OS X Finder are "quite foreign"?
>
>The FTP and SSH protocols are "quite foreign"?
>
>In EVERY other environment besides IMAP, you must create a directory 
>before you can put something into it.  In EVERY other environment besides 
>IMAP, directories don't vanish when you delete their children.
>
>The ONLY reason why IMAP hides directories under this cloak of "\NoSelect 
>names" was to pacify the CMU people who wanted to make everything look 
>like NetNews.  Giving in was a HUGE mistake which I have regretted 
>enormously ever since.

Sorry if I was unclear. As noted I wasn't talking about the creation 
action, but the concept of \NoSelect itself. I can't think of any object in 
any interface that the average person uses which has an analogue (except, 
obviously, for the ones of concern here--"directories" in mail clients 
which are either connecting to an IMAP server with a single-use mailbox 
format, or which hard-code a single-use view of the world).

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". If the idea of a non-selectable object is foreign to the 
very large majority of users then it would follow that the details of its 
creation/use/destruction would then also not have a ready mental map. But 
to get at the root a client designer might want to tackle creating a 
meaningful mental model of \NoSelect.

This is somewhat tangential to Timo's original topic; I only meant to 
address the client/user interaction point that came up.

-Brian

Brian Hayden writes:
> Sorry if I was unclear. As noted I wasn't talking about the creation 
> action, but the concept of \NoSelect itself. I can't think of any object in 
> any interface that the average person uses which has an analogue (except, 
> obviously, for the ones of concern here--"directories" in mail clients 
> which are either connecting to an IMAP server with a single-use mailbox 
> format, or which hard-code a single-use view of the world).
> 
> A directory in Windows, OS X, or most of the Linux desktop environments 
> (for example) is "selectable",

That depends on what you mean by "select". In a file browser it usually
means merely changing some context and listings. I don't think that's
analogous to IMAP "select"; opening an actual file is the analogous
operation, and you can't open a directory in this way.

My theory is that we have two competing models. The first, which is
Mark's if I've understood him correctly, is that selectable mailboxes are
"files". The second, which I suspect might be common amongst users, is that
messages are "files", and so the distinction between selectable and
unselectable mailboxes loses its most obvious analogy.

> both conceptually and in IMAP terms--because 
> it is "dual-use". If the idea of a non-selectable object is foreign to the 
> very large majority of users then it would follow that the details of its 
> creation/use/destruction would then also not have a ready mental map. But 
> to get at the root a client designer might want to tackle creating a 
> meaningful mental model of \NoSelect.

I think the only mental model which works is a tree. If messages are
the leaves, selectability of mailboxes seems weird because there's no
obvious reason why some arbitrary node can't have leaves attached to it.

On the other hand if selectable mailboxes are leaves then dual-use
mailboxes are difficult to understand. In fact dual-use mailboxes might
have encouraged, and not just allowed, the alternative model.

I would like to suggest that the kind of "one message can be in multiple
mailboxes" idea gmail is doing with "labels" might resolve the confusion,
but then there's the distinction between mailboxes and flags...

Cheers,

	- Joel

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.

A mailbox is not a directory.  It is an object containing messages, just 
like a text file is an object containing paragraphs of text.

A text file doesn't contain other files, nor does it contain executable 
programs.  It is single use, just as a directory is.

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.

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.

Brian Hayden writes:
> As noted I wasn't talking about the creation action, but the concept 
> of \NoSelect itself. I can't think of any object in any interface 
> that the average person uses which has an analogue

GUI toolkits do support it. In the one I wrote, something like
   i->setSelectable( false );
   i->setExpandable( true );
but it's not used much, because generally application developers want to 
find interfaces that cause less user grief (and fewer support calls).

Arnt

On Dec 30, 2009, at 12:51 AM, Joel Reicher wrote:

> Brian Hayden writes:
>> Sorry if I was unclear. As noted I wasn't talking about the creation
>> action, but the concept of \NoSelect itself. I can't think of any  
>> object in
>> any interface that the average person uses which has an analogue  
>> (except,
>> obviously, for the ones of concern here--"directories" in mail  
>> clients
>> which are either connecting to an IMAP server with a single-use  
>> mailbox
>> format, or which hard-code a single-use view of the world).
>>
>> A directory in Windows, OS X, or most of the Linux desktop  
>> environments
>> (for example) is "selectable",
>
> That depends on what you mean by "select". In a file browser it  
> usually
> means merely changing some context and listings. I don't think that's
> analogous to IMAP "select"; opening an actual file is the analogous
> operation, and you can't open a directory in this way.

>
> My theory is that we have two competing models. The first, which is
> Mark's if I've understood him correctly, is that selectable  
> mailboxes are
> "files". The second, which I suspect might be common amongst users,  
> is that
> messages are "files", and so the distinction between selectable and
> unselectable mailboxes loses its most obvious analogy.

Precisely. And I'll confirm your suspicion--this is a problem that's  
been studied, it isn't new. The IMAP model (the "Mark" model, which is  
just a consequent of the original unix mailbox model) is not how users  
think of things. It doesn't need to be--it's a protocol, not a user  
interface. But to just say that all the clients are "crappy" because  
they don't represent the protocol's foreign concepts in an easily  
digestible way may not be the most useful approach to the issue.

> I think the only mental model which works is a tree. If messages are
> the leaves, selectability of mailboxes seems weird because there's no
> obvious reason why some arbitrary node can't have leaves attached to  
> it.

Agreed. I suspect that the limitation existed as a consequent of the  
mbox format. And of course the attachment some people have to the  
concept because they're used to it--frankly I'm one of them. I find  
dual-use mailboxes messy and I despise them, but I have to accept that  
I'm in the minority. Most users like to to have both individual loose  
letters and a shoebox full of letters inside their dresser drawer.

> On the other hand if selectable mailboxes are leaves then dual-use
> mailboxes are difficult to understand. In fact dual-use mailboxes  
> might
> have encouraged, and not just allowed, the alternative model.



> I would like to suggest that the kind of "one message can be in  
> multiple
> mailboxes" idea gmail is doing with "labels" might resolve the  
> confusion,
> but then there's the distinction between mailboxes and flags...
>
> Cheers,
>
> 	- Joel
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20091230/bf167b3c/attachment.html>

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

Brian Hayden writes:
> 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.

A MIME part can contain text data too.

I think it's likely that users view messages as the "privileged" container
that is at the end of the name hierarchy only because they are using
interfaces that place it there. Being a container does not, in itself,
seem to give messages any kind of special status, because lots of other
things are containers too.

Cheers,

	- Joel

On Thu, 31 Dec 2009, Joel Reicher wrote:
> A MIME part can contain text data too.

A MIME part can contain a completely separate message too.

> I think it's likely that users view messages as the "privileged" container
> that is at the end of the name hierarchy only because they are using
> interfaces that place it there.

I agree.  Usability studies are rarely conducted in a completely unbiased 
and controlled setting; and thus quite often lead to predetermined 
answers.  Thus, we have atrocities (like the Microsoft ribbon or the Apple 
single-button mouse) which we were assured that usability studies had 
proven were the perfect interface.

The problem is that the very questions and framework of the study bias the 
answer.  It's like the political opinion polls commissioned by a political 
party.

> Being a container does not, in itself,
> seem to give messages any kind of special status, because lots of other
> things are containers too.

Yup.  Messages are not the end node of the name hierarchy; the mailbox is. 
If a message was the end node of the name hierarchy, there would be no 
need to select the mailbox prior to accessing the mailbox.  Select is a 
very different operation from descending the name hierarchy, and creates a 
very complex state.

It's easy to dismiss all this, because only a few IMAP clients are 
sophisticated enough to take advantage of this state.  The vast majority 
are glorified POP clients that babble IMAP protocol.  This came about 
because of the long-obsolete notion that Internet access is a difficult 
and expensive commodity that requires that the client must keep a mirror 
of what's on the server.  The success of webmail (which transforms the 
browser into the ultimate thin client) proves that this notion is complete 
nonsense today.  Yet people persist in claiming it.

Webmail won the war for the hearts and minds of users, not because webmail 
is so much better than IMAP, but rather because webmail is so much better 
than POP.

-- Mark --

http://panda.com/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Dec 30, 2009, at 1:19 PM, Mark Crispin wrote:

> On Thu, 31 Dec 2009, Joel Reicher wrote:
>
>> I think it's likely that users view messages as the "privileged"  
>> container
>> that is at the end of the name hierarchy only because they are using
>> interfaces that place it there.
>
> I agree.  Usability studies are rarely conducted in a completely  
> unbiased and controlled setting; and thus quite often lead to  
> predetermined answers.  Thus, we have atrocities (like the Microsoft  
> ribbon or the Apple single-button mouse) which we were assured that  
> usability studies had proven were the perfect interface.
>
> The problem is that the very questions and framework of the study  
> bias the answer.  It's like the political opinion polls commissioned  
> by a political party.

Your generalizations about usability studies are well and good--and  
have some truth to them, but are still generalizations. Let's get  
specific: I am talking about spontaneous utterances from people alone  
in a room doing normal tasks in an email client. Not answers to  
interview questions.

And fifteen years of help desk reports.

The average user views a message as privileged because it is the  
apparently atomic unit that they care about. Yes, I know it isn't  
atomic. Yes, I know it might contain a text/plain MIME part with the  
body, a text/html part with another version of the body, and three  
octet-stream parts that are GIFs... *but the user doesn't care*. I  
agree that being a container is not why it's special, precisely  
because the vast majority of users would never describe a message as a  
container. It's "the message" as a unit that they care about because  
that is how the human brain works. You send someone "a message"  
whether it's speaking a sentence to them or sending them a letter in  
the post.

> Yup.  Messages are not the end node of the name hierarchy; the  
> mailbox is. If a message was the end node of the name hierarchy,  
> there would be no need to select the mailbox prior to accessing the  
> mailbox.  Select is a very different operation from descending the  
> name hierarchy, and creates a very complex state.
>
> It's easy to dismiss all this, because only a few IMAP clients are  
> sophisticated enough to take advantage of this state.  The vast  
> majority are glorified POP clients that babble IMAP protocol.  This  
> came about because of the long-obsolete notion that Internet access  
> is a difficult and expensive commodity that requires that the client  
> must keep a mirror of what's on the server.  The success of webmail  
> (which transforms the browser into the ultimate thin client) proves  
> that this notion is complete nonsense today.  Yet people persist in  
> claiming it.

I'm not sure what this has to do with anything. People like us can  
discuss "the end node of the name hierarchy" all day, but users aren't  
interested until it has a meaningful translation into something useful.

More to the point: when *all* X have problem Y, a reasonable person  
needs to ask what might be causing Y--because it's unlikely that the  
designer of *every* X is precisely the same kind of stupid.

I'd draw your attention to a server behavior that you approved of  
earlier in the thread:

>> [1] "tag CREATE foo/"
> Same as "CREATE foo".
>> [2] "tag DELETE foo" where foo is selectable and has a child?
> Leave foo as \Noselect, don't delete children.
>> [3] "tag DELETE foo/bar" where foo is \NoSelect and bar is the only
>> child?
> Delete both foo/bar and foo.

This is unfriendly; a user never expects a parent to disappear simply  
because they deleted a child. Not only is it unexpected, but it's  
inconsistent; they can create an empty container, but it's removed  
unilaterally if it happens to become empty after it's had something in  
it?

How do you propose to communicate to a user the following:

"See this thing here? It's like a directory in your filesystem. Except  
it can only contain other directories that in turn contain text files  
and images--it can't contain any text or images itself. Oh, and if you  
have one of those directories underneath it that does contain text and  
images, and you delete that directory, this one will disappear too and  
you'll have to go to the trouble of recreating it next time you want  
to put something inside it.

Have fun!"

So what will happen is that you will create a server where actions  
have side effects that were not asked for and are not desired, so then  
clients will (each in their own hackish way) work around it, and then  
people like us will complain about the stupid clients.

You admitted earlier that the whole concept is a mistake that you  
regret; so I'm not sure what the use is of saying clients are "crappy"  
because they haven't come up with a good way to represent this thing  
that you acknowledge is a goofy kludge.

That was my point.

-Brian

On Wed, 30 Dec 2009, Brian Hayden wrote:
> This is unfriendly; a user never expects a parent to disappear simply because 
> they deleted a child. Not only is it unexpected, but it's inconsistent; they 
> can create an empty container, but it's removed unilaterally if it happens to 
> become empty after it's had something in it?

You just destroyed your own argument.

The disappearing parent problem happens precisely because, and is an 
unavoidable consequence, of the attitude that there should not be such a 
thing as a \NoSelect name without children.

If you paid attention to what I was saying, you would not have fallen into 
that trap.

You could sink yourself in deeper, by saying that you want to prohibit 
\NoSelect names.  As soon as you do that, the unavoidable consequence is 
that you prohibit deleting any mailbox that has children, and you prohibit 
creating any mailbox unless you create the parent mailbox.

But, you say, you didn't mean that at all; rather, you claim that the 
parent simply does not exist at all.  Then you have stepped on yet another 
landmine.  I'll leave it as an exercise for you to figure out.  Hint: 
regardless of whether or not the parent exists in your implementation, 
certain operations in IMAP require that it must exist (or more accurately 
must not not-exist) in some form.

Before assuming that you are smarter than the old guy, you ought to make 
sure that you really understand the problem.

The entire problem was caused because I gave in to people who thought like 
you, and allowed this half-assed copy of netnews hierarchy to happen (over 
the better judgement of my co-workers).  I should have required explicit 
directories (which can not have messages) and prohibited mailboxes from 
having children.  "Dual-use" mailboxes are a mess precisely because it is 
ambiguous whether to view the messages or view the children when you 
"open" it.  I also should have insisted that "/" be the one, and only, 
hierarchy delimiter.

Done right, \NoSelect would have been \Directory, and it would be 
prohibited to delete a directory with children.

-- Mark --

http://panda.com/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Dec 30, 2009, at 4:07 PM, Mark Crispin wrote:

> On Wed, 30 Dec 2009, Brian Hayden wrote:
>> This is unfriendly; a user never expects a parent to disappear  
>> simply because they deleted a child. Not only is it unexpected, but  
>> it's inconsistent; they can create an empty container, but it's  
>> removed unilaterally if it happens to become empty after it's had  
>> something in it?
>
> You just destroyed your own argument.
>
> The disappearing parent problem happens precisely because, and is an  
> unavoidable consequence, of the attitude that there should not be  
> such a thing as a \NoSelect name without children.
>
> If you paid attention to what I was saying, you would not have  
> fallen into that trap.
>
> You could sink yourself in deeper, by saying that you want to  
> prohibit \NoSelect names.  As soon as you do that, the unavoidable  
> consequence is that you prohibit deleting any mailbox that has  
> children, and you prohibit creating any mailbox unless you create  
> the parent mailbox.
>
> But, you say, you didn't mean that at all; rather, you claim that  
> the parent simply does not exist at all.  Then you have stepped on  
> yet another landmine.  I'll leave it as an exercise for you to  
> figure out.  Hint: regardless of whether or not the parent exists in  
> your implementation, certain operations in IMAP require that it must  
> exist (or more accurately must not not-exist) in some form.
>
> Before assuming that you are smarter than the old guy, you ought to  
> make sure that you really understand the problem.

In fact, I realize all of this, and did not destroy my argument--you  
misunderstand my argument because your focus is on discussing a  
related but separate issue. It's obviously not worth pursuing.

>
> The entire problem was caused because I gave in to people who  
> thought like you, and allowed this half-assed copy of netnews  
> hierarchy to happen (over the better judgement of my co-workers).  I  
> should have required explicit directories (which can not have  
> messages) and prohibited mailboxes from having children.  "Dual-use"  
> mailboxes are a mess precisely because it is ambiguous whether to  
> view the messages or view the children when you "open" it.  I also  
> should have insisted that "/" be the one, and only, hierarchy  
> delimiter.

No, in fact, you're wrong about what I think. I *agree* with you on  
this part, and have stated so explicitly. I dislike dual-use mailboxes  
and don't use them myself. But since they exist, people expect them to  
work like the nearest thing in their conceptual map (directories and  
files in a filesystem), and it's useful to think about how to get them  
to realize that there are subtle but important differences. Or change  
the client interaction so that it doesn't matter.

> Done right, \NoSelect would have been \Directory, and it would be  
> prohibited to delete a directory with children.

Yep. But we've got what we've got, so I'm more concerned with making  
the client implementation make sense to the innocent bystanders.

-Brian