- first STATUS (why status when you are anyway going to select the folder?)
- then SELECT
- then UID FETCH <last uid seen>:*
- then UID FETCH 1:<last uid seen>
To me it seems a bit overkill to do these operations
everytime you check manually/automatic for mail, maybe
in 100 folders . A mail server with HIGHESTMODSEQ/RFC4551
may be faster in this respect. I looked at the code and
saw the old approach only did the UID FETCH on folder select,
makes way more sense to me, however it seemed buggy according
to the comments of the code.
 from what I can see the only change you are not detecting with
the values obtained from SELECT is flag changes, since delete
changes will affect EXISTS and new mails will affect UIDNEXT.
Correct me if I am wrong.
I'm not sure about this email, it sounds like a bug report with no real
user question. I'm commenting below.
On Tue, 2017-01-31 at 22:35 +0100, Bo Simonsen via evolution-list
> To me it seems a bit overkill to do these operations
> everytime you check manually/automatic for mail,...
You are right, there is a room for improvements. Fox example: a) check
for flag changes on old messages only once per some time (ideally only
when the folder changed, which is not always noticeable); b) [related
to a)] do that only when the underlying folder structure is created,
though this breaks real trash/junk folders; c) do not check for old
mail changes on metered networks at all.
> A mail server with HIGHESTMODSEQ/RFC4551
> may be faster in this respect. I looked at the code and
> saw the old approach only did the UID FETCH on folder select,
What folder select do you mean, please? The 'select' word is ambiguous,
because the command sequence you mentioned also contains SELECT. The
Camel code doesn't know about "folder had been selected in the UI", it
only creates and disposes CamelFolder structure when needed and that is
related to b) from above.