Re: IMAP is a failure?

Bill Yeager <William.Yeager@eng.sun.com> Tue, 02 August 1994 20:51 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13717; 2 Aug 94 16:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13713; 2 Aug 94 16:50 EDT
Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa16613; 2 Aug 94 16:51 EDT
Received: by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA10666; Tue, 2 Aug 94 13:14:02 -0700
Errors-To: owner-imap@cac.washington.edu
X-Orig-Sender: owner-imap@cac.washington.edu
Return-Path: <William.Yeager@Eng.Sun.COM>
Received: from Sun.COM by mx1.cac.washington.edu (5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA10658; Tue, 2 Aug 94 13:14:00 -0700
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29304; Tue, 2 Aug 94 13:13:45 PDT
Received: from hape.eng.sun.com (hape-105) by Eng.Sun.COM (4.1/SMI-4.1) id AA08396; Tue, 2 Aug 94 13:13:56 PDT
Received: from roam by hape.eng.sun.com (5.0/SMI-SVR4) id AA29913; Tue, 2 Aug 1994 13:14:27 +0800
Date: Tue, 2 Aug 1994 13:11:41 -800 (PDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Yeager <William.Yeager@eng.sun.com>
Reply-To: William.Yeager@eng.sun.com
Subject: Re: IMAP is a failure?
To: bill@celestial.com, imap@cac.washington.edu, tomku@li.icl.se
Cc: Alex.Davidson@eng.sun.com
Message-Id: <Roam 1.0;775858301.9084.yeager.hape>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2417

> But isn't it true that IMAP is superior or equal in every perspective of POP
> functionality? Offline behavior isn't in the protocol, it's in the utilisation
> of the protocol. And by that you should be able to do all POP mailer things
> with IMAP as well.

Here at SMCC in the Nomadic systems group (mobile computing) we are especially interested in disconnected use and it is FOR THAT REASON that we use imap. 

We can either disconnect our client or be disconnected by a network drop, and still continue to process our mail. In the former case, we can of course fetch those messages we wish to use offline so to speak (trivial in imap and one can easily select today's messages, this week's messages or just a couple), and in the later case, we have what is there in our cache when the connection dropped. In either case  our system drops into record mode, simply recording the imap commands that would've been sent, and then when the system reconnects, these are played back after a consistency check is made on the remote mailbox.

It is remarkable what can be done given the flexibility and interoperability of IMAP. SInce our client is based on a full drag and drop paradigm, one can for example, drag and drop messages from the "browser window" into mailboxes that you have subscribed to, and of course one simply records a copy, and at reconnect time within a few seconds things are flying again. I don't have the time here to go into all of the fantastic things we have done with this great protocol. But, I'll close with one more: 

We are also very interested in low-band-width communications, and given such a situation, if one inadvertantly double-clicks requesting a large attachment, rather than have to just wait, the user can click the STOP button. Here a tcp urgent byte is sent to the server, and when the client receives a similar urgent byte from the server, then the transfer has been stopped. 

This can be done because IMAP allows one to selectively select body parts of a mime message. In our system they are simply a series of displayed icons. So, stopping such a transfer is just stopping the transfer of one body part.

We've made other modifications to the protocol to minimize bandwidth utilization, one of these has been put into IMAP4, and we'll be working on having others go into future imap versions. 

A GREAT protocol, and a great nomadic client.  The latter is called Roam.