In IMAP's RFC (6.3.1 SELECT Command) is described a one element of SELECT command response:
OK [UNSEEN <n>] The message sequence number of the first unseen message in the mailbox. If this is missing, the client can not make any assumptions about the first unseen message in the mailbox, and needs to issue a SEARCH command if it wants to find it.
So, I'm just thinking loud. Can we assume that there are no unseen messages in the mailbox when server doesn't include UNSEEN in the response? This is true for dovecot, how about others? We could skip one SEARCH call.
On Mon, 14 Jun 2010 13:56:25 +0200, "A.L.E.C" alec@alec.pl wrote:
In IMAP's RFC (6.3.1 SELECT Command) is described a one element of SELECT command response:
OK [UNSEEN <n>] The message sequence number of the first unseen message in the mailbox. If this is missing, the client can not make any assumptions about the first unseen message in the mailbox, and needs to issue a SEARCH command if it wants to find it.
So, I'm just thinking loud. Can we assume that there are no unseen messages in the mailbox when server doesn't include UNSEEN in the response? This is true for dovecot, how about others? We could skip one SEARCH call.
Directly contradicting the RFC? ;)
What about STATUS ... (UNSEEN)?
-Albert
List info: http://lists.roundcube.net/dev/
On 14.06.2010 14:27, Albert Lee wrote:
On Mon, 14 Jun 2010 13:56:25 +0200, "A.L.E.C"alec@alec.pl wrote:
The message sequence number of the first unseen message in the mailbox. If this is missing, the client can not make any assumptions about the first unseen message in the mailbox, and needs to issue a SEARCH command if it wants to find it.So, I'm just thinking loud. Can we assume that there are no unseen messages in the mailbox when server doesn't include UNSEEN in the response? This is true for dovecot, how about others? We could skip one SEARCH call.
Directly contradicting the RFC? ;)
For me, RFC is not clear here. It says about the first unseen message, not about any unseen message.
What about STATUS ... (UNSEEN)?
"STATUS command SHOULD NOT be used on the currently selected mailbox". and "Because the STATUS command is not guaranteed to be fast in its results, clients SHOULD NOT expect to be able to issue many consecutive STATUS commands and obtain reasonable performance".
So, STATUS cannot be used in all situations, but I'll take a look on this too.
On 14.06.2010 14:41, A.L.E.C wrote:
What about STATUS ... (UNSEEN)?
So, I have a patch. On dovecot STATUS looks a little bit faster than SELECT+SEARCH, but it can be used only when skip_deleted=false. Patch attached, if someone'd like to make more tests.
-
A.L.E.C -
Albert Lee