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
smime.p7s
Description: S/MIME cryptographic signature
