dovecot - Oct 2010 - Retrieving unread message count

Timo,

I'm working with a webmail client that periodically polls unread message
counts for a list of folders. It currently does this by doing a LIST or LSUB
and then iterating across all of the folders, running a SEARCH ALL UNSEEN,
and counting the resulting UID list.

Eventually I'd like to see it using RFC5819 LIST-EXTENDED, but that requires
a fair bit of work. In the mean time I'm trying to speed up the existing
iteration. I've got it working using 'STATUS "mailbox"
(UNSEEN)', but the
language in RFC3501 suggest that this may be slow. There is a
counterproposal to use RFC4731 ESEARCH and do 'SELECT
"MAILBOX"'; 'SEARCH
RETURN (COUNT) UNSEEN'.
>From an IMAP server perspective, which do you anticipate would be faster?
>From a client perspective it seems like STATUS would be better since it
involves less round-trips to the server and less output parsing, but given
the warnings in the RFCs there is concern that it is in fact be more
expensive.

-Brad

On 17.10.2010, at 23.49, Brandon Davidson wrote:
> Eventually I'd like to see it using RFC5819 LIST-EXTENDED, but that
requires
> a fair bit of work. In the mean time I'm trying to speed up the
existing
> iteration. I've got it working using 'STATUS "mailbox"
(UNSEEN)', but the
> language in RFC3501 suggest that this may be slow. There is a
> counterproposal to use RFC4731 ESEARCH and do 'SELECT
"MAILBOX"'; 'SEARCH
> RETURN (COUNT) UNSEEN'.
The reason why STATUS is mentioned to be possibly slow is to discourage clients
from doing a STATUS to all mailboxes.
>> From an IMAP server perspective, which do you anticipate would be
faster?
>> From a client perspective it seems like STATUS would be better since it
> involves less round-trips to the server and less output parsing, but given
> the warnings in the RFCs there is concern that it is in fact be more
> expensive.
STATUS is definitely faster than SELECT+SEARCH with all IMAP servers.