mailing list archives

Hi list,

I'm trying to understand what is the more efficient way to maintain the
number of unseen messages of the currently selected mailbox. RFC3501 says a
client must not issue a STATUS command to a selected mailbox and that
information sent by a SELECT is enough.

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

I think it works pretty well when the mailbox is opened only once. Let's
imagine this mailbox is opened twice, by different clients. If one client
marks a message as \Seen, how can the second client know about this change?

Thanks for your help,

Antoine Nguyen
http://modoboa.org/

> 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

Le 15/04/2012 15:12, Barry Leiba a ?crit :
>
> 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).
Now that you mention it, I do :-)
As I said, it was just an *idea* about how I could achieve that...
>
> 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.
>
Ok, I understand.

Indeed, my client doesn't take advantage at all of what IMAP offers. 
Reading your answer, I think I have a better view of the logic behind 
the procotol and it clearly appears that I can't create an efficient 
client without a proper caching mechanism.

Anyway, thanks for your explanation.

Antoine