Hey there,
before I file a ticket, I'd like to find out a little more about what might be causing this - so please help me :)
This is SVN revision 247:
When sorting by date (displaying Messages 1 to 64 of 1211) with the arrow in the "Date" column pointing up (sorry forthis, but I really can't figure out how it's _supposed_ to be sorted...), the sorting is pretty much random I'll give you a little overview:
1 Sun 14:50 (Source: Date: Sun, 16 Jul 2006 14:50:51 +0200) 2 09.02.2006 17:14 (Source: Date: Thu, 09 Feb 2006 16:14:58 +0100) 3 10.02.2006 18:47 (Source: Date: Fri, 10 Feb 2006 17:47:48 +0100) 4 17.03.2006 18:11 (Source: Date: Fri, 17 Mar 2006 17:11:25 +0100) .. 15 12.07.2006 14:51 (Source: Date: Wed, 12 Jul 2006 14:51:53 +0200) 16 Tue 14:04 (Source: Date: Tue, 18 Jul 2006 14:04:36 +0200) 17 11.01.2006 12:20 (Source: Date: Wed, 11 Jan 2006 11:20:53 +0100) .. 62 12.07.2006 14:37 (Source: Date: Wed, 12 Jul 2006 14:37:47 +0200) 63 Sat 19:54 (Source: Date: Sat, 15 Jul 2006 19:54:03 +0200) 64 Sun 14:53 (Source: Date: Sun, 16 Jul 2006 14:53:13 +0200)
This happens with both Pretty Dates on and off, and in several folders in a similar way.
I hope this helps!
mtu
Hi there,
On 7/20/06, Eric Stadtherr estadtherr@gmail.com wrote:
I've noticed weird date sorting too. I haven't done exhaustive analysis, but my hypothesis is that the sorting is by the date the message appeared in the folder, not the date it was sent/received. Is that consistent with what you're seeing?
Would that be a nice feature / option? To have both sorting methods (sent/received, folder appearance) available? If this happens to be the case anyhow.
Regards,
Martin
Eric Stadtherr wrote:
I've noticed weird date sorting too. I haven't done exhaustive analysis, but my hypothesis is that the sorting is by the date the message appeared in the folder, not the date it was sent/received. Is that consistent with what you're seeing?
I've sorted the files in the correpsonding folder by date (ls -t) and checked both the newest and the oldest ones, but I can't confirm that this affects the searching. It just appears to be totally random.
~Mik
Michael Bueker wrote:
before I file a ticket, I'd like to find out a little more about what might be causing this - so please help me :)
This is SVN revision 247:
When sorting by date (displaying Messages 1 to 64 of 1211) with the arrow in the "Date" column pointing up (sorry forthis, but I really can't figure out how it's _supposed_ to be sorted...), the sorting is pretty much random I'll give you a little overview:
1 Sun 14:50 (Source: Date: Sun, 16 Jul 2006 14:50:51 +0200) 2 09.02.2006 17:14 (Source: Date: Thu, 09 Feb 2006 16:14:58 +0100) 3 10.02.2006 18:47 (Source: Date: Fri, 10 Feb 2006 17:47:48 +0100) 4 17.03.2006 18:11 (Source: Date: Fri, 17 Mar 2006 17:11:25 +0100) .. 15 12.07.2006 14:51 (Source: Date: Wed, 12 Jul 2006 14:51:53 +0200) 16 Tue 14:04 (Source: Date: Tue, 18 Jul 2006 14:04:36 +0200) 17 11.01.2006 12:20 (Source: Date: Wed, 11 Jan 2006 11:20:53 +0100) .. 62 12.07.2006 14:37 (Source: Date: Wed, 12 Jul 2006 14:37:47 +0200) 63 Sat 19:54 (Source: Date: Sat, 15 Jul 2006 19:54:03 +0200) 64 Sun 14:53 (Source: Date: Sun, 16 Jul 2006 14:53:13 +0200)
This happens with both Pretty Dates on and off, and in several folders in a similar way.
I hope this helps!
Could it be your IMAP server returning them in this order? What IMAP server are you using?
I'm using Courier on one of my RC setups, and in a couple rudimentary tests, it sorted properly. I took a really old message and stuck it in a folder, and checked it in Thunderbird and Roundcube - When sorted by date in RC it was in the proper order, and in TB it has an option to sort by received order, and in that case it showed up last, as it was the 'newest' entry in the folder. So for me it appears to be working fine with Courier.
Also, are those message dates right? If you view the source of those messages that are in the middle of the list, and check the headers, do the times the server received the message match up with what's reported in the Date field? Just curious.
Jim
On Jul 20, 2006, at 6:25 PM, Jim Pingle wrote:
Michael Bueker wrote:
before I file a ticket, I'd like to find out a little more about what might be causing this - so please help me :)
This is SVN revision 247:
When sorting by date (displaying Messages 1 to 64 of 1211) with the arrow in the "Date" column pointing up (sorry forthis, but I really can't figure out how it's _supposed_ to be sorted...), the sorting is pretty much random I'll give you a little overview:
1 Sun 14:50 (Source: Date: Sun, 16 Jul 2006 14:50:51 +0200) 2 09.02.2006 17:14 (Source: Date: Thu, 09 Feb 2006 16:14:58 +0100) 3 10.02.2006 18:47 (Source: Date: Fri, 10 Feb 2006 17:47:48 +0100) 4 17.03.2006 18:11 (Source: Date: Fri, 17 Mar 2006 17:11:25 +0100) .. 15 12.07.2006 14:51 (Source: Date: Wed, 12 Jul 2006 14:51:53 +0200) 16 Tue 14:04 (Source: Date: Tue, 18 Jul 2006 14:04:36 +0200) 17 11.01.2006 12:20 (Source: Date: Wed, 11 Jan 2006 11:20:53 +0100) .. 62 12.07.2006 14:37 (Source: Date: Wed, 12 Jul 2006 14:37:47 +0200) 63 Sat 19:54 (Source: Date: Sat, 15 Jul 2006 19:54:03 +0200) 64 Sun 14:53 (Source: Date: Sun, 16 Jul 2006 14:53:13 +0200)
This happens with both Pretty Dates on and off, and in several
folders in a similar way.I hope this helps!
Could it be your IMAP server returning them in this order? What
IMAP server are you using?I'm using Courier on one of my RC setups, and in a couple
rudimentary tests, it sorted properly. I took a really old message and stuck it in a
folder, and checked it in Thunderbird and Roundcube - When sorted by date
in RC it was in the proper order, and in TB it has an option to sort by
received order, and in that case it showed up last, as it was the 'newest'
entry in the folder. So for me it appears to be working fine with Courier.Also, are those message dates right? If you view the source of those messages that are in the middle of the list, and check the headers,
do the times the server received the message match up with what's reported
in the Date field? Just curious.Jim
Just to add fuel to this fire, I'm transitioning from Cyrus 2.2 to
Dovecot, and the same mailbox in both sorts all wrong with Cyrus, and
just fine with Dovecot.
The same mailboxes display and sort properly in Thunderbird when
coming from both server software.
-- Mark Edwards
On Thu, 20 Jul 2006 18:38:59 -0700, Mark Edwards mark@antsclimbtree.com wrote:
Just to add fuel to this fire, I'm transitioning from Cyrus 2.2 to
Dovecot, and the same mailbox in both sorts all wrong with Cyrus, and
just fine with Dovecot.
This thing gets ever stranger! Dovecot is my IMAPd, and it is involved in the wrong sorting.
I will try to remove dovecot's index files from those folders when I'm back home. Maybe they contain something wrong somehow, and regenerating them helps.
mtu
Jim Pingle wrote:
Could it be your IMAP server returning them in this order? What IMAP server are you using?
An experiment turned out the following:
I entered the folder in question, deleted all the dovecot index files, opened the folder in thunderbird (new header download) and then in roundcube - the sorting was still wrong, but _different_.
So those files probably do have to do with it.
mtu
Michael Bueker wrote:
Jim Pingle wrote:
Could it be your IMAP server returning them in this order? What IMAP server are you using?
An experiment turned out the following:
I entered the folder in question, deleted all the dovecot index files, opened the folder in thunderbird (new header download) and then in roundcube - the sorting was still wrong, but _different_.
So those files probably do have to do with it.
Interesting. Unfortunately I'm not quire sure how this could be worked around in RC, given that it relies on the server returning the right chunk of messages in the right order... If I've read the code right, it asks the server to give "messages 41 to 80 sorted by date" and the server only returns that set of headers.
It's easy for Thunderbird or a traditional client to just download all the headers and sort them itself, but in a webmail app that could mean a big cut in speed, especially for large mailboxes.
Jim
On Fri, 21 Jul 2006 17:49:46 -0400, Jim Pingle lists@pingle.org wrote:
Interesting. Unfortunately I'm not quire sure how this could be worked
around in RC, given that it relies on the server returning the right chunk
of messages in the right order... If I've read the code right, it asks the
server to give "messages 41 to 80 sorted by date" and the server only
returns that set of headers.
It's easy for Thunderbird or a traditional client to just download all the
headers and sort them itself, but in a webmail app that could mean a big
cut in speed, especially for large mailboxes.
You're probably right, but I don't think blaming the IMAPd and looking away isn't the best thing to do. This wrong sorting is MOST annoying, and apparently happens with more than one IMAPd. Maybe someone should talk to the dovecot/Cyrus developers about their interface, but in the meantime, we should think about handling sorting ourselves.
mtu
On Jul 24, 2006, at 2:18 AM, Michael Bueker wrote:
On Fri, 21 Jul 2006 17:49:46 -0400, Jim Pingle lists@pingle.org
wrote:Interesting. Unfortunately I'm not quire sure how this could be
workedaround in RC, given that it relies on the server returning the
right chunkof messages in the right order... If I've read the code right, it
asks theserver to give "messages 41 to 80 sorted by date" and the server only
returns that set of headers.
It's easy for Thunderbird or a traditional client to just download
all theheaders and sort them itself, but in a webmail app that could mean
a bigcut in speed, especially for large mailboxes.
You're probably right, but I don't think blaming the IMAPd and
looking away isn't the best thing to do. This wrong sorting is MOST
annoying, and apparently happens with more than one IMAPd. Maybe
someone should talk to the dovecot/Cyrus developers about their
interface, but in the meantime, we should think about handling
sorting ourselves.
Incidentally, Squirrelmail doesn't have the problem. Same server,
same mailbox. Squirrelmail has server-side sorting enabled.
Roundcube sorts all out of order, Squirrelmail gets it right.
This is with Cyrus 2.2.
-- Mark Edwards
Michael Bueker wrote:
You're probably right, but I don't think blaming the IMAPd and looking away isn't the best thing to do. This wrong sorting is MOST annoying, and apparently happens with more than one IMAPd. Maybe someone should talk to the dovecot/Cyrus developers about their interface, but in the meantime, we should think about handling sorting ourselves.
I totally agree, I just wasn't sure how easily it can be fixed.
Mark Edwards wrote:
Incidentally, Squirrelmail doesn't have the problem. Same server, same mailbox. Squirrelmail has server-side sorting enabled. Roundcube sorts all out of order, Squirrelmail gets it right.
This is with Cyrus 2.2.
I wonder how IlohaMail sorts in the same configuration, given that RC's IMAP lib is based on that. Is anyone with this problem able to try it?
I suppose someone may have to tcpdump the interaction between the IMAP server and both squirrelmail and roundcube to look for differences in the requests. That, or dig through the IMAP library source code.
I have roundcube and squirrelmail on one of my servers, but it's running Courier not Cyrus so I'm not sure how much help that would be.
In Squirrelmail's configuration you have to tell it what type of IMAP server you're using, so they may have some workarounds for various IMAP implementation differences. Unfortunately, doing some quick checks (grep -ri cyrus *, etc) through my copy of squirrelmail's source doesn't turn up any workarounds for sorting, just for folder management.
Jim
Jim Pingle wrote:
Mark Edwards wrote: Incidentally, Squirrelmail doesn't have the problem. Same server, same mailbox. Squirrelmail has server-side sorting enabled. Roundcube sorts all out of order, Squirrelmail gets it right.
This is with Cyrus 2.2.
I suppose someone may have to tcpdump the interaction between the IMAP server and both squirrelmail and roundcube to look for differences in the requests. That, or dig through the IMAP library source code.
I hate to reply to myself, but I was checking into this when I discovered that with server-side sorting enabled, Squirrelmail gets it wrong for me. With server-side sorting off, it sorts properly.
A tcpdump of the IMAP sessions of both shows that Squirrelmail is sorting using ARRIVAL and Roundcube is sorting using DATE. Also, Squirrelmail is supplying an encoding type to the server of "ISO-8859-1" whereas Roundcube is sending "US-ASCII" in the same situation.
Checking the code of Squirrelmail shows that if you have the personal option "Sort by Received Date" set to yes, it sends ARRIVAL to the server as the sort choice, whereas if you have it set to no, it sends DATE. When I was testing, the option was set to Yes; When I changed it to No, it sorted as expected.
There appears to be support for a similar option in the code for roundcube (in imap.inc), but I see no method for a user/admin to set it. In rcube_imap.inc it's explicitly set off, but at the start of imap.inc it is set on. It tests to see if IMAP_USE_HEADER_DATE is false which it always will be as I can't find any other reference to the variable it's testing for anywhere in the code.
As an experiment you could try commenting out line 57 in program/lib/imap.inc: if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true;
Alternately, change that so it's set to false instead of true.
If it alters the sorting behavior for you, we may have found the culprit...
Jim
On Jul 24, 2006, at 9:17 AM, Jim Pingle wrote:
There appears to be support for a similar option in the code for
roundcube (in imap.inc), but I see no method for a user/admin to set it. In rcube_imap.inc it's explicitly set off, but at the start of
imap.inc it is set on. It tests to see if IMAP_USE_HEADER_DATE is false which it
always will be as I can't find any other reference to the variable it's
testing for anywhere in the code.As an experiment you could try commenting out line 57 in program/ lib/imap.inc: if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true;
Alternately, change that so it's set to false instead of true.
If it alters the sorting behavior for you, we may have found the
culprit...
Unfortunately, that did nothing. :-(
Squirrelmail get the sort right on this particular mailbox, whether
server-side sorting is enabled or not. Roundcube puts a bunch of old
mails out of order at the top of the box.
-- Mark Edwards
Jim Pingle wrote:
Checking the code of Squirrelmail shows that if you have the personal option "Sort by Received Date" set to yes, it sends ARRIVAL to the server as the sort choice, whereas if you have it set to no, it sends DATE. When I was testing, the option was set to Yes; When I changed it to No, it sorted as expected.
That makes sense, since the Date header lines I posted initially were correct, just not in the correct order.
There appears to be support for a similar option in the code for roundcube (in imap.inc), but I see no method for a user/admin to set it. In rcube_imap.inc it's explicitly set off, but at the start of imap.inc it is set on. It tests to see if IMAP_USE_HEADER_DATE is false which it always will be as I can't find any other reference to the variable it's testing for anywhere in the code.
As an experiment you could try commenting out line 57 in program/lib/imap.inc: if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true;
That sounds very promising, I'm gonna try that.
mtu
I found the problem and I have a patch almost ready. My fix is working
for small folders but it doesn't handle multi-page message lists yet.
I'll post it as soon as it's done!
-Eric
Eric Stadtherr wrote:
I did some digging into this issue over the weekend, and discovered that rcube_imap::_list_headers is getting a correctly sorted list of message UIDs back from iil_C_Sort(). This means that the sorting within the IMAP server (mine is dovecot) is being done correctly, but RC is still displaying them in an incorrect order (the order of UIDs in the display table doesn't match the order of UIDs that come back from iil_C_Sort(). I didn't get a chance to trace it any further through rcube_imap::_fetch_headers and out through the display code.
On Mon, 24 Jul 2006 09:49:23 -0700, Mark Edwards wrote:
On Jul 24, 2006, at 9:17 AM, Jim Pingle wrote: > There appears to be support for a similar option in the code for > roundcube > (in imap.inc), but I see no method for a user/admin to set it. In > rcube_imap.inc it's explicitly set off, but at the start of > imap.inc it is > set on. It tests to see if IMAP_USE_HEADER_DATE is false which it > always > will be as I can't find any other reference to the variable it's > testing for > anywhere in the code. > > As an experiment you could try commenting out line 57 in program/ > lib/imap.inc: > if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true; > > Alternately, change that so it's set to false instead of true. > > If it alters the sorting behavior for you, we may have found the > culprit... Unfortunately, that did nothing. :-( Squirrelmail get the sort right on this particular mailbox, whether server-side sorting is enabled or not. Roundcube puts a bunch of old mails out of order at the top of the box. -- Mark Edwards
Hi,
Actually RoundCube should attempt to sort the message set retrieved from the server again because you can't be sure that the messages are returned in the right sequence. This is done in rcube_imap.inc on line 571/572 but those lines were commented out in revision 203 by myself (shame on me!). Making use of iil_SortHeaders() again should solve the problem. If not, we should try to improve the sorting algorithm in that function.
Regards, Thomas
2006/7/26, Eric Stadtherr estadtherr@gmail.com:
All,
I found the problem and have completed the fix. Essentially what was happening is that the "SORT" command to the IMAP server would return the message sequence numbers in the correctly sorted order. RC would then perform a "FETCH" command to get the message header data, using the ordered sequence numbers that came back from the SORT. Unfortunately, the IMAP server is free to ignore the order of the sequence numbers provided in the FETCH command (see RFC 3501 §9, "sequence-set"), so it was returning the headers in ascending sequence number order (ignoring the sorted order). The subsequent RC code assumed that the FETCH command returned the messages in the requested order, causing the incorrect order in the display.
I may have overengineered the fix, but I haven't noticed any performance hit at all. I put the patch at:
http://stadtherr.bounceme.net/files/rc_sort_fix.patch
Someone will have to let me know how best to get the fix incorporated (I don't have SVN access).
Enjoy!
-Eric
PS. I haven't tested it with caching turned on, since I like to leave that off If someone has caching enabled and wants to test this, can you let me know how it works?
On Mon, 24 Jul 2006 22:44:46 -0600, Eric Stadtherr wrote:
I found the problem and I have a patch almost ready. My fix is working for small folders but it doesn't handle multi-page message lists yet. I'll post it as soon as it's done!-Eric
Eric Stadtherr wrote:
I did some digging into this issue over the weekend, and discovered that rcube_imap::_list_headers is getting a correctly sorted list of message UIDs back from iil_C_Sort(). This means that the sorting within the IMAP server (mine is dovecot) is being done correctly, but RC is still displaying them in an incorrect order (the order of UIDs in the display table doesn't match the order of UIDs that come back from iil_C_Sort(). I didn't get a chance to trace it any further through rcube_imap::_fetch_headers and out through the display code.
On Mon, 24 Jul 2006 09:49:23 -0700, Mark Edwards wrote:
On Jul 24, 2006, at 9:17 AM, Jim Pingle wrote:There appears to be support for a similar option in the code for roundcube (in imap.inc), but I see no method for a user/admin to set it. In rcube_imap.inc it's explicitly set off, but at the start of imap.inc it is set on. It tests to see if IMAP_USE_HEADER_DATE is false which it always will be as I can't find any other reference to the variable it's testing for anywhere in the code.
As an experiment you could try commenting out line 57 in program/ lib/imap.inc: if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true;
Alternately, change that so it's set to false instead of true.
If it alters the sorting behavior for you, we may have found the culprit...
Unfortunately, that did nothing. :-(
Squirrelmail get the sort right on this particular mailbox, whether server-side sorting is enabled or not. Roundcube puts a bunch of old mails out of order at the top of the box.
-- Mark Edwards
Thomas Bruederli wrote:
Actually RoundCube should attempt to sort the message set retrieved from the server again because you can't be sure that the messages are returned in the right sequence. This is done in rcube_imap.inc on line 571/572 but those lines were commented out in revision 203 by myself (shame on me!). Making use of iil_SortHeaders() again should solve the problem. If not, we should try to improve the sorting algorithm in that function.
That's it!
Uncommenting those lines works, and I have not noticed any significant slowdown either. So we've solved this one :)
mtu
I found that I also had to comment the lines below them, like so:
// if not already sorted
if (!$headers_sorted)
$a_msg_headers = iil_SortHeaders($a_msg_headers, $this-
sort_field, $this->sort_order);
// if (!$headers_sorted && $this->sort_order == 'DESC') // $a_msg_headers = array_reverse($a_msg_headers);
Perhaps that's because I am using an older trunk, from a week ago or
so. Anyway, just my 2 cents.
I agree with Eric, why not respect the sort that the IMAP server
performed? Shouldn't that be authority? Or at least have it
configurable (allow server-side sorts, like with Squirrelmail).
On Jul 26, 2006, at 8:48 AM, Eric Stadtherr wrote:
Thomas,
That's essentially what I did in my fix - use the sequence returned
by the IMAP SORT command to re-order the list returned by the FETCH
command.The only problem with using iil_SortHeaders to sort the fetched
list is that it implements its own sorting algorithm, ignoring the
sequence returned by the SORT command. The algorithm probably
produces the same results, but why tell the IMAP server to sort the
list and then throw away the results? I think we need to choose one
or the other - tell the IMAP server to sort the list, or execute
our own sorting algorithm. I vote for letting the IMAP server do
the sort - this automatically gives us support for any future IMAP
sorting behavior without having to maintain our own algorithms.Thoughts?
On Wed, 26 Jul 2006 09:23:16 +0200, "Thomas Bruederli" wrote:
Hi,
Actually RoundCube should attempt to sort the message set retrieved from the server again because you can't be sure that the messages are returned in the right sequence. This is done in rcube_imap.inc on line 571/572 but those lines were commented out in revision 203 by myself (shame on me!). Making use of iil_SortHeaders() again should solve the problem. If not, we should try to improve the sorting algorithm in that function.
Regards, Thomas
2006/7/26, Eric Stadtherr :
All,
I found the problem and have completed the fix. Essentially what
was happening is that the "SORT" command to the IMAP server would
return the message sequence numbers in the correctly sorted order.
RC would then perform a "FETCH" command to get the message header
data, using the ordered sequence numbers that came back from the
SORT Unfortunately, the IMAP server is free to ignore the order of
the sequence numbers provided in the FETCH command (see RFC 3501
§9, "sequence-set"), so it was returning the headers in ascending
sequence number order (ignoring the sorted order). The subsequent
RC code assumed that the FETCH command returned the messages in the
requested order, causing the incorrect order in the display.I may have overengineered the fix, but I haven't noticed any
performance hit at all. I put the patch at:
http://stadtherr.bounceme.net/files/rc_sort_fix.patch
Someone will have to let me know how best to get the fix
incorporated (I don't have SVN access).
Enjoy!
-Eric
PS. I haven't tested it with caching turned on, since I like to
leave that off If someone has caching enabled and wants to test
this, can you let me know how it works?On Mon, 24 Jul 2006 22:44:46 -0600, Eric Stadtherr wrote:
I found the problem and I have a patch almost ready.My fix is working for small folders but it doesn't handle multi- page message lists yet. I'll post it as soon as it's done!
-Eric
Eric Stadtherr wrote:
I did some digging into this issue over the weekend, and
discovered that rcube_imap::_list_headers is getting a correctly
sorted list of message UIDs back from iil_C_Sort(). This means
that the sorting within the IMAP server (mine is dovecot) is being
done correctly, but RC is still displaying them in an incorrect
order (the order of UIDs in the display table doesn't match the
order of UIDs that come back from iil_C_Sort(). I didn't get a
chance to trace it any further through rcube_imap::_fetch_headers
and out through the display code.On Mon, 24 Jul 2006 09:49:23 -0700, Mark Edwards wrote:
On Jul 24, 2006, at 9:17 AM, Jim Pingle wrote:There appears to be support for a similar option in the code for roundcube (in imap.inc), but I see no method for a user/admin to set it. In rcube_imap.inc it's explicitly set off, but at the start of imap.inc it is set on. It tests to see if IMAP_USE_HEADER_DATE is false which it always will be as I can't find any other reference to the variable it's testing for anywhere in the code.
As an experiment you could try commenting out line 57 in program/ lib/imap.inc: if (!$IMAP_USE_HEADER_DATE) $IMAP_USE_INTERNAL_DATE = true;
Alternately, change that so it's set to false instead of true.
If it alters the sorting behavior for you, we may have found the culprit...
Unfortunately, that did nothing. :-(
Squirrelmail get the sort right on this particular mailbox, whether server-side sorting is enabled or not. Roundcube puts a bunch of
old
mails out of order at the top of the box.
-- Mark Edwards
-- Mark Edwards
Hi Eric,
I absolutely agree with your suggestion. Your sorting class seems to do a better job than iil_SortHeaders does. Unfortunately I didn't read your patch first and just looked for my faults because sorting once worked in RoundCube. I will add your patch to the Trunk and replace the old sorting behavior.
Thanks a lot! Thomas
2006/7/26, Eric Stadtherr estadtherr@gmail.com:
- Zitierten Text ausblenden -
Thomas,
That's essentially what I did in my fix - use the sequence returned by the IMAP SORT command to re-order the list returned by the FETCH command.
The only problem with using iil_SortHeaders to sort the fetched list is that it implements its own sorting algorithm, ignoring the sequence returned by the SORT command. The algorithm probably produces the same results, but why tell the IMAP server to sort the list and then throw away the results? I think we need to choose one or the other - tell the IMAP server to sort the list, or execute our own sorting algorithm. I vote for letting the IMAP server do the sort - this automatically gives us support for any future IMAP sorting behavior without having to maintain our own algorithms.
Thoughts?
-
Eric Stadtherr -
Jim Pingle -
Mark Edwards -
Martin Adler -
Michael Bueker -
Thomas Bruederli