> Aaron, > > I've reverted _ic_sort behaviour to pre-2.0.3. Can you confirm this wrt > twig? > > This has given me something to think about: > > - Leif interleaved the sort with the search code. There are some valid > reason's for doing so, but we need to > treat the search arguments fundamentally differently from the sort keys, > where they are currently part of the > same struct. Messy. > > - Given that my understanding of the current sort code is less than > perfect, I suggest that the sort keys > *not* be used for search commands, as is now (partly) the case. Instead, > the search keys should be used for > determining the result set, and next the sort keys should be used for > reordering the set. This, it seems, > would require the search run to use the sort keys for retrieving all the > message attributes that will later on > be used for sorting. > >
I would say that as the _ic_sort was mostly just a stop gap untill we had header caching available, that it is obvious the whole sort part of dbmail should be reworked, however the current implementation is near optimal for at least the sort needed for squirrelmail, as you mentioned before I never intended this to be anything but for SM. If anyone has time to work on code I would urge we focus on header caching so as to be able to make the sort and other items work well for 2.1 and leave the sort code that was merged into 2.0 as is and make a not that it is intened for SM only, or add a option to enable the sort code and runtime...etc. Thanks, Leif
