37 lines
1.5 KiB
Plaintext
37 lines
1.5 KiB
Plaintext
MBOX-Line: From mrc at CAC.Washington.EDU Wed Oct 31 08:56:12 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <mrc@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:40 2018
|
|
Subject: [Imap-protocol] Re: Multiappend
|
|
In-Reply-To: </WSAeLSOZbzLiQ4knqfbnA.md5@libertango.oryx.com>
|
|
References: </WSAeLSOZbzLiQ4knqfbnA.md5@libertango.oryx.com>
|
|
Message-ID: <alpine.OSX.0.9999.0710310825570.20419@pangtzu.panda.com>
|
|
|
|
On Wed, 31 Oct 2007, Arnt Gulbrandsen wrote:
|
|
> if I understand you correctly, you're saying that one should use multiappend
|
|
> to transfer an entire mailbox with one command.
|
|
|
|
Yes. We use this functionality. A lot.
|
|
|
|
> I was afraid that someone might do that, so I didn't implement multiappend. I
|
|
> know people whose average mailbox size is 200MB (no idea what the top decile
|
|
> looks like ;) and transactions that large could be a problem. Single IMAP
|
|
> commands that large could be a problem, too. My code would have real problems
|
|
> with it.
|
|
|
|
I can understand the problem your implementation. In my implementation,
|
|
lots of little transfers are far more harmful for the server than one big
|
|
one. The RTTs, the vastly increased number of error points, and having to
|
|
do the overhead of APPEND per message (check out, lock, append, unlock,
|
|
check in) is devastating.
|
|
|
|
I will insist that multiappend be in the base of any IMAP5. It was an
|
|
oversight that it was not there in the first place.
|
|
|
|
-- Mark --
|
|
|
|
http://panda.com/mrc
|
|
Democracy is two wolves and a sheep deciding what to eat for lunch.
|
|
Liberty is a well-armed sheep contesting the vote.
|
|
|