Hello,
I still have the very same problem that was discussed in this thread, also with Cyrus IMAP.
I just did the tests with manually sending the SORT commands and got: .. c3 OK Completed (30994 msgs in 0.170 secs) .. c4 OK Completed (30994 msgs in 0.130 secs)
So sorting is really fast, and appears to work.
I'm still having this problem with the 20060413 snapshot, so the problem appears to remain, even though this thread died...?
I'm testing with a mailbox with a little over 30000 messages in it, and RC brings up the message list just fine (could be faster, but it's acceptable), but then completely chokes if you try to open one of the messages.
It appears to be the same problem, it dies when trying to get the next/previos IDs.
This line in program/steps/mail/show.inc appears to be where everything times out:
$a_msg_index = $IMAP->message_index(NULL, $_SESSION['sort_col'], $_SESSION['sort_order']);
So I tried to look into what message_index does (program/include/rcube_imap.inc), and found that RC appears to be doing client side sorting of the list, even though my IMAP server supports sorting!!
What I found was that
$this->get_capability('sort')
returns true, but
$a_index = iil_C_Sort($this->conn, $mailbox, $this->sort_field)
returns false!
This clearly has to be the problem, right?
Is there any reason why iil_C_Sort should return false under any normal circumstances where the server supports sorting?
Capabilities/server type, for reference:
- OK <hostname> Cyrus IMAP4 v2.2.12 server ready
00 CAPABILITY
- CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR 00 OK Completed
Regards, Håkan Lindqvist