MBOX-Line: From jkt at flaska.net  Mon Feb 18 10:23:41 2013
To: imap-protocol@u.washington.edu
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Re: QRESYNC & Long Command Lines
In-Reply-To: <20130218002432.Horde.oHbZYiST0vPMI_hKIDlLvg1@bigworm.curecanti.org>
References: <20130218002432.Horde.oHbZYiST0vPMI_hKIDlLvg1@bigworm.curecanti.org>
Message-ID: <2deda4fd-081b-4b1c-9702-269c3b6bca25@flaska.net>

On Monday, 18 February 2013 08:24:32 CEST, Michael M Slusarz wrote:
> The concern is that I know at least some IMAP servers have a 
> hard ~8KB  limit on any command.  This limit would render 
> QRESYNC useless on  mailboxes over a certain size - or at least 
> diminish the usefulness of  the SELECT/EXAMINE QRESYNC 
> parameters.

My client doesn't use the known-uids argument (we always build and maintain the full seq-UID mapping), so I have not spent much time reasoning about that argument. However, Trojita sends a list of known seq-uid pairs. The list is built similarly to the example in RFC5162 by halving the intervals between the included UIDs, starting in the middle of the mailbox (i.e. if the mailbox contains 1000 messages, the first UID belongs to the message #500, the second one to #750, the third one to #875 etc). It's a rather crude heuristic assuming that the probability of an expunge lowers proportionally to how long the message has been present in the mailbox.

I believe that clients should always send the fourth argument to prevent a pathologic case of QRESYNC where it is in fact less efficient than a session without QRESYNC, see the example on page 6 of the RFC. My guess (not based on any evidence) is that it's reasonable to assume that servers do not maintain a list of expunges indefinitely and that it's plausible that the client will every now and then sync using a HIGHESTMODSEQ which the server no longer remembers. If that is the case and the currently assigned UIDs are sparse, QRESYNC will have to return more data than a simple UID SEARCH ALL, so in my opinion it makes sense to send O(log2 n) extra numbers in each sync. Your expected usage pattern might be different, though.

Now, about the third argument, the known-uids -- Timo's suggestion is a good one. What to do here depends on how you handle the FLAGS. If you cache them in a persistent location, it probably makes sense to always send a big enough range of UIDs so that the IMAP server can notify you upon sync time about any changes, eliminating the need to explicitly FETCH FLAGS later on (and to keep track of which messages have fresh flags and which are stale). If you, however, always show just a subset of messages to the user, it might be reasonable to get rid of this client-side caching and to not cache the UIDs for messages which are never going to be shown.

CONDSTORE and QRESYNC are life savers for clients that maintain a fully synchronized view of the whole mailbox (speaking about FLAGS and UIDs now, *not* envelopes and other immutable data!) such as Trojita. If your client is 
optimized towards a different goal, especially when you do not cache flags between sessions and your knowledge of the UID-seq mapping is sparse, it seems to me that these extensions do not provide much benefit over simply doing a sync with the facilities from baseline RFC3501. I might be wrong, as always, so please feel free to correct me.

With kind regards,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

