[Dovecot] 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.
Timo,
On 10/17/10 3:56 PM, "Timo Sirainen" tss@iki.fi wrote:
The reason why STATUS is mentioned to be possibly slow is to discourage clients from doing a STATUS to all mailboxes.
STATUS is definitely faster than SELECT+SEARCH with all IMAP servers.
That's what I figured, thanks! Other than actually calling THREAD and counting the resulting groups, is there a good way to get a count of threads?
-Brad
Timo,
On 10/17/10 4:20 PM, "Timo Sirainen" tss@iki.fi wrote:
On 18.10.2010, at 0.19, Brandon Davidson wrote:
Other than actually calling THREAD and counting the resulting groups, is there a good way to get a count of threads?
Nope, that's the only way.
It looks like draft-ietf-morg-inthread-01 dropped THREADROOT/THREADLEAF which is too bad. It would be really nice to be able to do something like:
s01 SEARCH RETURN (COUNT) THREADROOT INTHREAD
It looks like it's still pretty much a work in progress, but are you planning on implementing any more of the INTHREAD stuff?
-Brad
On Sun, 2010-10-17 at 21:11 -0700, Brandon Davidson wrote:
It looks like draft-ietf-morg-inthread-01 dropped THREADROOT/THREADLEAF which is too bad. It would be really nice to be able to do something like:
s01 SEARCH RETURN (COUNT) THREADROOT INTHREAD
Yeah, I was almost going to suggest that first.
It looks like it's still pretty much a work in progress, but are you planning on implementing any more of the INTHREAD stuff?
Maybe some day..
Anyway, the main problem with THREADROOT was that it's possible to have a thread in THREAD reply that has an invisible root message (2+ messages have the same In-Reply-To: header but the parent doesn't exist). So it wouldn't really have worked the way you wanted anyway.
participants (2)
-
Brandon Davidson
-
Timo Sirainen