No, this question is OK for this forum.
I looked at implementing SORT several times during the v4.5 dev process - I know that many people using webmail systems would find it useful. The problem is that, like almost everything else in IMAP, the SORT command is ludicrously complicated internally - it looks as though the authors have tried to accommodate every possible scenario they could think of, and then made it so that the only acceptable implementation is a full implementation.
From the Mercury perspective, the problem with SORT is that it requires me to support sorting on information that I don't have easy access to - this is particularly true of the THREADS=REFERENCES sub-mode, where thread sorting is based on the "References" and "In-reply-to" fields of the message. The pre-parsed index structures used by Pegasus Mail (and thus by extension, Mercury) vastly predate the widespread use of these headers, and as a result, they are not included. This means that in order to perform a sort, I would have to re-parse the entire folder in a custom pass, which would be extremely slow. There's also the problem that "References" headers can be of arbitrary length, making memory considerations an issue.
Now, I know that other IMAP servers have found ways around these problems, but they all have the luxury (usually) of having started with a largely blank slate. Because I've been around for so much longer than practically all of them (with the possible exception of the Washington IMAP server), I have a huge amount of legacy data I have to be able to handle, and that complicates things considerably.
I certainly intend to support SORT (and probably other IMAP extensions as well), but it's not a trivial modification and will require some fairly fundamental low-level changes to the way Mercury works.
Cheers!
-- David --
No, this question is OK for this forum.
I looked at implementing SORT several times during the v4.5 dev process - I know that many people using webmail systems would find it useful. The problem is that, like almost everything else in IMAP, the SORT command is ludicrously complicated internally - it looks as though the authors have tried to accommodate every possible scenario they could think of, and then made it so that the only acceptable implementation is a full implementation.
From the Mercury perspective, the problem with SORT is that it requires me to support sorting on information that I don't have easy access to - this is particularly true of the THREADS=REFERENCES sub-mode, where thread sorting is based on the "References" and "In-reply-to" fields of the message. The pre-parsed index structures used by Pegasus Mail (and thus by extension, Mercury) vastly predate the widespread use of these headers, and as a result, they are not included. This means that in order to perform a sort, I would have to re-parse the entire folder in a custom pass, which would be extremely slow. There's also the problem that "References" headers can be of arbitrary length, making memory considerations an issue.
Now, I know that other IMAP servers have found ways around these problems, but they all have the luxury (usually) of having started with a largely blank slate. Because I've been around for so much longer than practically all of them (with the possible exception of the Washington IMAP server), I have a huge amount of legacy data I have to be able to handle, and that complicates things considerably.
I certainly intend to support SORT (and probably other IMAP extensions as well), but it's not a trivial modification and will require some fairly fundamental low-level changes to the way Mercury works.
Cheers!
-- David --
