MBOX-Line: From slusarz at curecanti.org  Sat Mar  2 20:28:05 2013
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Re: QRESYNC & Long Command Lines
In-Reply-To: <2deda4fd-081b-4b1c-9702-269c3b6bca25@flaska.net>
References: <20130218002432.Horde.oHbZYiST0vPMI_hKIDlLvg1@bigworm.curecanti.org>
	<2deda4fd-081b-4b1c-9702-269c3b6bca25@flaska.net>
Message-ID: <20130302212805.Horde.Q2lND55F8fxpy0sVKrcluQ8@bigworm.curecanti.org>

Quoting Jan Kundr?t <jkt@flaska.net>:

> 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.

I would partially disagree about this statement.  I think that  
CONDSTORE/QRESYNC is MORE important for newer, more disconnected  
clients - think mobile than more traditional clients.

Traditional flag syncing, e.g. UID FETCH <known UID list> (FLAGS), can  
potentially be an expensive operation bandwidth wise for a mobile  
client.  Couple that with the fact that a wireless connection can cut  
in/out frequently, and these costs can add up.

Say a mobile client is caching 200 messages.  Let's say this client is  
polling for new mail every 5 minutes (push notifications/IDLE may not  
always be available since the connection may not be constant).  An  
average FETCH response might be about 50 bytes.  Assume that no flag  
changes take place in the mailbox at all.

That's 120,000 bytes of additional network traffic an hour (I'm going  
to assume CONDSTORE/QRESYNC command syncing traffic is negligible)  
that has to be parsed to determine that nothing has changed in the  
mailbox.  120,000 bytes for a desktop computer over an hour on a  
decent network connection is minimal.  On a mobile device, having to  
parse this additional traffic might add up to 1-2 minutes less  
battery.  (Under this scenario, that would be ~85 MB of extra traffic  
a month.  Considering that some mobile plans are limited to 1-2 GB of  
traffic a month, that is a substantial chunk of traffic being used)

And this is just CONDSTORE.  VANISHED responses w/QRESYNC eliminate  
the need to do UID synchronization to check for deleted messages.

All this being said... I don't think any of the decent Android e-mail  
clients (e.g. stock client, k-9 mail) implement QRESYNC, let alone  
CONDSTORE.  Don't know about the iOS client.  If this is indeed true,  
they are missing out on at least some resource savings.

michael


