MBOX-Line: From janssen at parc.com  Mon Mar 12 15:55:39 2007
To: imap-protocol@u.washington.edu
From: Bill Janssen <janssen@parc.com>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] how long can APPEND take? 
In-Reply-To: <18599.1173734925.056533@peirce.dave.cridland.net> 
References: <07Mar12.121950pst."57996"@synergy1.parc.xerox.com>
	<18599.1173734925.056533@peirce.dave.cridland.net>
Message-ID: <07Mar12.145541pst."57996"@synergy1.parc.xerox.com>

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.

> An APPEND should never take more than a couple of seconds. There's no 
> point in scanning images at this point, instead, have your system 
> append the message instantly, and then scan through the messages 
> later to classify them. They're not going to be spam, since they've 
> been explicitly added by the user.

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.

But if the clients won't tolerate it, they won't tolerate it.

> FWIW, users expect that a delivery is pretty well instant too, in 
> fact, so I think you're doomed to failure here.

I get that a lot :-).

Bill

