[Imap-uw] Outlook deadlock

[Mark Crispin]

On Tue, 18 Sep 2007, Andy Lyttle wrote:
> Many users are paying a flat monthly rate for broadband access, or are on a 
> LAN with a 100Mbps connection to the server.

Many users are indeed on fast flat rate links.

But there are also many users who still use dialup, or s-l-o-w 256K DSL. 
These users are facing increased download times for all their spam.

More importantly, there are a growing number of users who use wireless. 
As with cable modems, "unlimited" does not really mean unlimited in the 
world of wireless; nor is all wireless fast WiFi.  Furthermore, if you 
happen to be roaming, you will discover that lovely phenomenum that the 
Japanese call "pake-shi" ("death by packet").

I prefer to architect systems that work work in all environments, and not 
necessarily assume that I have a 100MB unmetered pipe.  I also believe in 
scaling to large (5 and 6 digit message counts, GB sizes) mailboxes, even 
when the client is a bitty box on a slow, expensive link.

>> I also doubt that many of them think "gee, when I delete a whole bunch of 
>> messages at once I want to wait several minutes while they are all copied 
>> to the Trash mailbox.  I just *love* watching that animation of stuff being 
>> moved."
> Apple's Mail does this in the background, so users don't see a progress bar 
> unless they want to (Window / Activity Viewer).  I'm not sure about 
> Thunderbird.

So, instead of seeing the animation, the user either gets to watch an 
hourglass or the user's client forks off yet another session to the 
server.  Not an improvement in my book.

> True.  A better implementation would be to display a virtual "Trash" folder, 
> that would display all messages that have been marked for deletion.  Dragging 
> a message from there back to the folder it's really in would simply clear the 
> deleted flag, or dragging it to a different folder might copy it silently.

My point exactly!

>> On both Windows (and modern MacOS) you can get to a command prompt and 
>> delete large numbers of files without going through an excruciatingly long 
>> move to trash, albeit at the cost of not having an undelete.
> Actually, moving to trash doesn't take long at all, even for huge numbers of 
> files.  It's just moving to a different directory on the same filesystem, not 
> copying the data - that's why there are multiple trash folders.

Umm...that is not my experience.  I have spent several minutes on both 
MacOS and Windows waiting for a "move to Trash" operation on thousands of 
files to complete.  These days, I go into the command prompt.

>> Rather, it's in order to satisfy those who were brought up on the MacOS way 
>> of doing things, and haven't yet grasped that external interfaces and 
>> internal details are not necessarily the same.
> Are you referring to users or developers?

I'm referring to developers.  Most users generally follow whatever they 
were told by the first person who taught them "how to use the computer." 
Most users are concerned with good design, rather than specific design 
elements.

This last is an important point.  MacOS and Windows both have good design. 
The common Linux GUIs, although sharing a great many design elements with 
MacOS and Windows, do not.

Any specific design element is neither sufficient, nor necessary, for good 
design; it's what is done with those design elements.

> Mac OS X Leopard will be out in a couple months, with a completely new 
> version of Mail.  Hopefully that will address most of your issues, and if 
> not, file more.

Apple knows how to contact me, and I know that their users have been 
complaining about issues with Mail.app.  The onus should not be on me to 
beg them to pay attention (or pay them for a new operating system that I 
don't need).

> What specifically should they be doing, that they're not?  I'm curious as to 
> what participation in the IMAP protocol community entails.

There are active mailing lists and working groups of IMAP developers 
(e.g., imap-protocol, imapext), who exchange information about 
implementation techniques, do interoperability testing, and discuss 
extensions to the protocol.  A start is to join the mailing list.  A 
further step is to participate in interoperatility testing.

-- Mark --

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