This was argued at considerable length a few years ago; you may want to review the archives.
The problem with trying to subset the output of SORT is multifold: The simpleminded idea of "just show n entries starting at the m-th entry" doesn't work with THREAD. THREAD is more much useful and popular than SORT; the overwhelming majority of people who use any sort of non-arrival display choose threading over sorting. The "m-th entry" is not the correct focus. New messages can cause the "n entries starting at the m-th entry" to be a completely different set of messages than what is currently displayed. A better focus is "n entries in the vicinity of message sequence m"; but even that can be disconcerting if m isn't chosen correctly (and the client probably can't choose m correctly if it doesn't know the complete SORT results). Doing subsetting in a way that works with THREAD and has correct focus turns out to be very complex. There is an "attractive nuisance" aspect in terms of server CPU burden (as in re-sorting multiple times). This may be ameliorated by having the server "remember" previous SORTs if no messages were added or expunged. But it's an additional implementation burden. Speaking as someone who has probably more experience with slow links and IMAP than anyone else, SORT and THREAD results do not figure highly in perceived performance compared to other aspects of IMAP. IMAP is a chatty protocol, and many IMAP clients exacerbate the problem with unnecessary or even wrong-headed protocol operations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
