On Mon, Jan 24, 2005, ""Leif Jackson"" <[EMAIL PROTECTED]> said:

> 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.

Header caching isn't an option for 2.0, so we need to make it work
reliably and as fast as possible within its database schema. I do know
that SquirrelMail is more common than TWIG, but more importantly,
SquirrelMail has its own IMAP client library written in PHP whereas TWIG
uses PHP's copy of the c-client library. It would not surprise me if many
more PHP email programs are not working with 2.0.3, either, though I
haven't looked into it.

What specifically makes the _ic_sort code work for SquirrelMail that can't
be extended for other clients and/or for a more general case?

And, more broadly, if _ic_sort is really _ic_sort_smhack, what can we do
so that the hack is only used if we've really got SquirrelMail on the
line?

Aaron

Reply via email to