MBOX-Line: From MRC at CAC.Washington.EDU  Mon Mar 12 16:36:33 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] how long can APPEND take?
In-Reply-To: <1173742339.9167.48.camel@hurina>
References: <07Mar12.121950pst."57996"@synergy1.parc.xerox.com>
	<18599.1173734925.056533@peirce.dave.cridland.net>
	<07Mar12.145541pst."57996"@synergy1.parc.xerox.com>
	<1173742339.9167.48.camel@hurina>
Message-ID: <alpine.WNT.0.83.0703121633380.7904@Tomobiki-Cho.CAC.Washington.EDU>

On Tue, 13 Mar 2007, Timo Sirainen wrote:
>> I suppose I could stick a crippled substandard version of the message
>> into the server's data store immediately, report APPEND success
>> immediately, and have that message suddenly disappear if the full
>> incorporation later fails, and be replaced by a real message if it
>> later succeeds.  I'm a bit concerned about client-side caching of
>> the data.
> If you're going to replace the message, change its UID as well.

I second this comment.  Messages are static; they MUST NOT be changed. 
The only want to change a message on the server is to add a new message 
with the change, and delete/expunge the old copy.

This is very imporant and bears emphasis: messages are static; they MUST 
NOT be changed.

> How about hanging SEARCH until the message is indexed? Clients are used
> to long running SEARCH, and the user most likely is doing SEARCHes a lot
> less than APPENDs (and SEARCHes after APPEND even less often).

I certainly am not used to long-running SEARCH.  I expect even a text 
SEARCH to return quickly, or at least as fast as the data can be read from 
the disk.

-- Mark --

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

