Aaron Stone wrote:
We're not getting to 2.1 anytime soon,
Not true. cvs-head doesn't have many, if any, regressions at the moment. It already has fixed a significant number of bugs that are marked as wont-fix for 2.0
If we make a concerted effort, 2.1.0 can be released in no time at all. In fact, I'd very much like to release 2.1.0 before I start depending on the header tables.
Ilja, I'll prepare cvs-head for 2.1.0 release (tag dbmail_2_1_0_release) today. I just committed all remaining pending changes before 2.1.0 and will start testing with different clients before I do the actual tagging. Can you release later this week if I give the go ahead signal?
and I don't want to leave this broken in 2.0 if we can make a sane set of workarounds.
Since we've fixed all the major bugs in 2.0 I think the time has come to at least start thinking about putting 2.0 in maintenance mode. All I have to do is convince a guy named Aaron :-)
Which is to say, all of the strings that are "recognized" and then skipped because the code says TODO are essentially silent failures to perform the requested sort command. That's not OK. If we get a string that we don't have the SQL to handle, then we should give a suitable error message and allow the client to work around us.
I do agree here. Silent failures are not good. But they've also been in there since 2.0.0.
I'll start reading through this part of the code, as I've never done much work on the IMAP side of things. What I'd like to do is take a survey of the SORT command options, and then see what sort of SQL we can reasonably do, and then work backwards saying, "We have SQL than can do X, Y and Z so we'll only accept SORT strings involving X, Y and Z. If the SORT string asks for Q, then we give an error."
Even knowing what sort of sql we can do given the 2.0 database layout is not enough. I think Leif will agree the sort code was not designed with even a semblance of full compliance in mind. It also leans too heavily on the search code to extract strict sort functionality from it.
I'd say: leave it be. -- ________________________________________________________________ Paul Stevens [EMAIL PROTECTED] NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands_______________________________________www.nfg.nl
