The IMAP THREAD extension implements threading entirely on the server. The client never actually receives the threading information. The server simply lists the messages in threaded order, and the client displays them accordingly.
But that is not what you said -- you said that IMAP has no provision to retrieve message threading information. Perhaps it depends on your point of view.
Yes, I was specifically referring to the following sequence of historical events:
A) Certain self-appointed guardians of IMAP pureness, that shall remain nameless, deride and mock anyone who does not use the divinely-approved mechanism for obtaining message summary, being IMAP FETCH ENVELOPE. This command returns a pre-processed message summary: sender, recipients, subject, date, etc... Mail clients which, instead, request raw header content, and parse it themselves, are labeled as inferior crapware.
B) IMAP FETCH ENVELOPE has a rigid, well-defined structure, containing a specific list of fields in a specific format.
C) This all happened before everyone figured out that hierarchical threading is cool.
D) IMAP FETCH ENVELOPE does not include the parsed References: header -- basically what's needed into to do hierarchical threading.
E) Therefore, it becomes necessary for IMAP clients to FETCH an additional request for the References: header, in addition to ENVELOPE. And, since now multiple items are requested, the server is permitted to return them in any arbitrary relative order, which the client must be capable of handling.
That gives you the executive capsule summary of the current state of things. Well, that's neither here, nor there. It turns out that changing the Cone client to add a second request for the References: header, and still maintain overall sanity, wasn't too bad. Now, I need to figure out how to format the threaded display...
I believe that implementing this type of functionality in the server is the wrong approach. Server resources are limited. You have several hundred clients, and now the server has to burn CPU cycles sorting folders for each client. Meanwhile, the clients are sitting idle, with plenty of CPU power to spare.
Sometimes, servers are vastly more powerful than clients. Indeed, some
But, there are more clients than a single server. It does you no good to have a server whose CPU is twice as fast as the client's, when the server now has to divide that CPU to service a hundred other clients.
So, in the end the client's worth of server resources is, mathematically speaking, 1/50th of its own available resources.
clients are little more than glorified remote xterms with limited memory resources, etc... Part of the whole reason IMAP exists, IMO.
IMAP exists as a means of providing network access to a mailbox. Now, the secondary trend of piling on all sorts of client-related processing into the server is where I think things are going too far.
If both Cone and pine are asked to sort a folder, by the time Cone finishes sorting its folder, the poor server, where pine has logged into, is yet to receive pine's command.
Actually, I'm pretty sure PINE doesn't use server threading, either. But, I was wrong once.
Pine, if the server advertizes the IMAP THREAD capability, will use it. Otherwise, it will do it on its own (fetch the headers of every message, chew on it, spit it out).
Since cone likely implements the same or a similar threading algorithm to courier-imap's, that's great! And for most people, a good thing.
Not just, yet. For now, only generic folder sorting options are available: by name, subject, date, etc...
------------------------------------------------------- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
