[Imap-protocol] how long can APPEND take?

[Timo Sirainen]

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: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://mailman1.u.washington.edu/pipermail/imap-protocol/attachments/20070313/6e1282c4/attachment-0001.bin