> 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.
>
> 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.
I thought about making it a specific hack but then I knew it would be a
wast of time when we got to x.x version of dbmail with header cahcing
where it can be done right. Anyway I agree with you guys, and say leave
2.0.x alone with the _ic_sort and just make a push to make it right for
2.1 ..etc. Tho latly I have been way to busy to help so you can ignore me
if you want :)
-leif
>
> Aaron
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
