31 lines
1.3 KiB
Plaintext
31 lines
1.3 KiB
Plaintext
MBOX-Line: From janssen at parc.com Mon Mar 12 17:10:26 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: <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: <07Mar12.161031pst."57996"@synergy1.parc.xerox.com>
|
|
|
|
> If you're going to replace the message, change its UID as well.
|
|
|
|
I think I only need to do this if the underlying changes are visible
|
|
through the IMAP protocol. The only real difference is that they
|
|
would be returned by BODY or TEXT searches that previously didn't
|
|
|
|
> 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).
|
|
|
|
The main reason I'm not using an existing IMAP server is that I can't
|
|
stand the long-running searches, so that doesn't appeal to me.
|
|
|
|
Could I just not do APPEND? What's it used for, anyway? Drafts,
|
|
copying messages from folders on other mail servers, etc.
|
|
|
|
Bill
|
|
|