MBOX-Line: From tss at iki.fi  Mon Mar 12 16:32:19 2007
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] how long can APPEND take?
In-Reply-To: <07Mar12.145541pst."57996"@synergy1.parc.xerox.com>
References: <07Mar12.121950pst."57996"@synergy1.parc.xerox.com>
	<18599.1173734925.056533@peirce.dave.cridland.net>
	<07Mar12.145541pst."57996"@synergy1.parc.xerox.com>
Message-ID: <1173742339.9167.48.camel@hurina>

On Mon, 2007-03-12 at 15:55 -0700, Bill Janssen 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.

> Well, by the user's client.  The problem is that this approach makes
> those not-yet-scanned messages invisible to the search mechanism, so
> that it becomes (to the user) flaky.  "I just put that message in
> here!  Where is it!"  Not sure whether I want an apparently slow
> server, or an apparently flaky search system.  Frankly, I'd rather
> just hang the connection till it's done.  Seems more compliant to me.
> Shame there's not some untagged hinting the APPEND command could
> generate to estimate a time-to-incorporation.

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).

If you don't want the UID replacing, you could hang FETCH too I suppose.

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