MBOX-Line: From barryleiba at computer.org  Sun Apr 15 06:12:47 2012
To: imap-protocol@u.washington.edu
From: Barry Leiba <barryleiba@computer.org>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] Unseen messages question
In-Reply-To: <4F8A7B7E.9080709@ngyn.org>
References: <4F8A7B7E.9080709@ngyn.org>
Message-ID: <CAC4RtVACuVrnaXZ_ado6CP-Hg3pLN83sK-0JnGiki3i-qXE0JA@mail.gmail.com>

> I'm trying to understand what is the more efficient way to maintain the
> number of unseen messages of the currently selected mailbox.
...
> My current idea follows these steps :
> * Issue a STATUS before the mailbox is selected => ?I know how many unseen
> messages it contains
> * SELECT the mailbox => ?I got the eventual first unseen message in this
> mailbox but I don't understand how this info can be useful
> * Maintain the unseen counter (on client side) according to what the user do
> * Send a NOOP command every X minutes and look at the RECENT response to
> see if there are new messages

You realize that there's a race condition in that plan, right?  If a
new message arrives between the STATUS and SELECT commands, you won't
have it in your unseen count.  You could mitigate that by also
considering UIDNEXT, but that still leaves the second-client issue (if
another client makes an existing message seen or unseen between the
commands, you'll still be wrong).

The usefulness of the "first unseen" number is to allow you to limit
FETCH or SEARCH commands to that.  The right way to handle this is to
SELECT the mailbox and use the first-unseen value as bounds for a
FETCH FLAGS command or a SEARCH UNSEEN command.  Those will give you
more than just the count -- they'll also give you the message numbers
of all the unseen messages, along with any other information you
choose to collect if you do FETCH (you might also want UIDs, or
whatever).

Once you have that information, any changes made by new messages or
other clients should come in unsolicited FETCH responses (for flag
changes) and EXISTS responses (for new messages).

But you might really reconsider the whole client caching model you're
using.  If you think that the unseen count alone is sufficiently
useful, maybe your client isn't doing all it could do to take
advantage of what IMAP has to offer.

Barry

