All, Just as a note I never intended for this code to get back ported to 2.0, so I guess if you guys want to work it out that is cool, however my vote would be to remove it rather than fix it and have a patch on the side if someone wants to fool with it. Otherwise I think it is a waste of time to work on the code for 2.0 as it is limted by the parsing system and other issues people are improving on in 2.1.
just my .02 -leif > I'm putting the two strands of this thread back together ;-) ... > > On Tue, Jan 25, 2005, ""Leif Jackson"" <[EMAIL PROTECTED]> said: > >>> 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 :) > > We're not getting to 2.1 anytime soon, and I don't want to leave this > broken in 2.0 if we can make a sane set of workarounds. 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 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. >> >> Accualy paul you could do this with a search of the cmd string to set a >> key for reverse and then just tell my btree code not to re-order the >> mid's >> as it takes them in reverse to being with if I rember correctly. > > 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." > > Aaron > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
