[Imap-protocol] how long can APPEND take?
tss at iki.fi
Mon Mar 12 16:32:19 PDT 2007
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
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
More information about the Imap-protocol