MBOX-Line: From dave at cridland.net  Wed Mar 28 02:50:09 2007
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] MULTIAPPEND and LITERAL+
In-Reply-To: <alpine.WNT.0.83.0703271036260.5820@Tomobiki-Cho.CAC.Washington.EDU>
References: <673436100.23171175014561192.JavaMail.root@dogfood.liquidsys.co
	m> <alpine.WNT.0.83.0703271036260.5820@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <29159.1175071809.584580@peirce.dave.cridland.net>

On Tue Mar 27 18:57:02 2007, Mark Crispin wrote:
> I don't think that a client should use LITERAL+ with MULTIAPPEND.  
> Both LITERAL+ and MULTIAPPEND are optimizations to reduce RTTs, but 
> MULTIAPPEND is better for the APPEND case.  Although it sounds 
> attractive to eliminate all per-message RTTs by using both 
> simultaneously (and IMAP specifically does NOT preclude doing so), 
> any failure will cause both client and server to go to a lot of 
> work for nothing.

Just to pick up on that point, Polymer assumes (rightly in all the 
few cases I tried) that the server will refuse an APPEND as early as 
possible. I don't think there's anything encouraging this in RFC3501 
or RFC3502 (although maybe there is), but I think it's good behaviour 
as well as common.

Polymer chooses to exploit this by not using LITERAL+ only for the 
first literal in any command which exceeds a certain size, to allow 
the server to reject it. So typical small text-only messages will end 
up using non-synchronizing literals, whereas the first large 
attachment will use a synchronizing literal, so that Polymer knows 
earlier when to send it. This seems to work better than avoiding 
LITERAL+ with APPEND entirely, although there's no doubt it could do 
with some refinement - in particular, several thousand small messages 
will all be sent using non-synchronizing literals, which is an 
obvious problem.

It's also worth noting that the same applies to APPENDs whether 
MULTIAPPEND or CATENATE is used or not - Polymer's doing this for all 
commands, it's merely that unless it encounters seriously 
impressively sized mailbox names, it's unlikely to occur elsewhere.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

