Aaron Stone wrote:
On Tue, Jan 25, 2005, Paul J Stevens <[EMAIL PROTECTED]> said:
I was pleasantly surprised by your command trace yesterday. Apparently
c-client is smart. Smart enough to hide server-errors from the client.
The fact that
A01 SORT (REVERSE ARRIVAL) US-ASCII ALL
failed is very important in this respect. The build_imap_search function
is full of TODO statements for search keys that are silently ignored
whereas US-ASCII and UTF-8 which are both explicitely required...
[snip]
Looks like SORT (ARRIVAL) US-ASCII ALL kinda works in 2.0.3, because for
ARRIVAL, there's:
if(sorted && (strcasecmp(search_keys[*idx], "arrival") == 0)) {
key.type = IST_SORT;
strncpy(key.search, "order by pms.internal_date", MAX_SEARCH_LEN);
(*idx)++;
Whereas (REVERSE ARRIVAL) fails because REVERSE doesn't work. In 2.0.2,
US-ASCII itself threw an error, and so in both cases fallbacks were used.
So REVERSE ARRIVAL can be done just with a "desc" in the "order by"
clause. However REVERSE with any of the other sorts, working or not, won't
work.
I tried that yesterday. Won't work even for ARRIVAL, because of the way the
result set is constructed in db_search. But perhaps I was just being dense.
That US-ASCII isn't recognized at all means that a fallback is always
used. I would be interested in seeing the command that SquirrelMail uses.
Perhaps we'd be much better off replacing the tries-to-be-general _ic_sort
with an actual hack -- one that recognizes specific SORT commands that we
know we can implement and that we've seen used by clients in the wild.
jikes :-)
--
________________________________________________________________
Paul Stevens [EMAIL PROTECTED]
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl
