59 lines
2.9 KiB
Plaintext
59 lines
2.9 KiB
Plaintext
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
|
|
|
|
|