On Thu, 29 May 2003, Sam Varshavchik wrote: > Bruno Postle writes: > > > On Thu 29-May-2003 at 02:35:39 -0500, Jon Nelson wrote: > >> On Thu, 29 May 2003, Sam Varshavchik wrote: > >> > >> > There is no IMAP provision to retrieve message threading > >> > information, so it needs to be done by hand. > >> > >> What about the THREADING extension to IMAP? > > > > Indeed, courier-imap itself implements IMAP threading quite nicely. > > 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. > 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 clients are little more than glorified remote xterms with limited memory resources, etc... Part of the whole reason IMAP exists, IMO. > A server has better things to do than to fuss around with the order of the > individual messages shown on each client's screen. This is why Courier-IMAP > has an option to disable this extension, forcing clients to do their own > dirty work. > > Cone tries to place as little load on the server as possible. If you note, > paging through a large folder, or changing the sorting order, does not > involve any server activity. All header information is saved in memory. > With a server-centric approach, re-threading a folder with a thousand > messages will require at least 5Kb's worth of network traffic: the client > request, and the server response, consisting of message numbers in the > arranged sort order. So now the client has to send the command, spin its > wheels, hoping that the server is not already loaded, then reading a list of > all message numbers, in thread order. > > 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. In either case, my experiences with a myriad of clients and their (each in their own way, broken) threading implementations leads me to believe that *if* a server supports threading, and the server's implementation isn't broken (JWZ's approach comes to mind as one that isn't), then /all/ clients that support /server-side threading/ automatically get non-broken threading for free. 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. To conclude: don't misunderstand my remarks as saying I think implementing threading in cone is a bad idea. If it's done right, it's a fine idea. However, I don't completely agree with you regarding server-side threading. -- Feast your Vulcan squinties on that! Jon Nelson <[EMAIL PROTECTED]> C and Python Code Gardener ------------------------------------------------------- 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
