From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9490 Path: main.gmane.org!not-for-mail From: visigoth@naiad.fac.cs.cmu.edu Newsgroups: gmane.emacs.gnus.general Subject: Round two of requests for new optional methods. Date: 21 Jan 1997 03:09:15 -0500 Sender: visigoth@naiad.fac.cs.cmu.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.93) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035149508 18808 80.91.224.250 (20 Oct 2002 21:31:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:31:48 +0000 (UTC) Return-Path: Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.8.4/8.8.4) with SMTP id AAA07048 for ; Tue, 21 Jan 1997 00:22:10 -0800 Original-Received: from naiad.fac.cs.cmu.edu (NAIAD.FAC.CS.CMU.EDU [128.2.191.173]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Tue, 21 Jan 1997 09:09:28 +0100 Original-To: ding@ifi.uio.no Original-Lines: 79 X-Mailer: Red Gnus v0.76/XEmacs 19.14 Source-Info: Sender is really visigoth@naiad.fac.cs.cmu.edu Xref: main.gmane.org gmane.emacs.gnus.general:9490 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9490 [ I expect this to be "theoretical for qgnus" talk, but figured I'd throw it on the table since it's been much on my mind lately. Flame away. :) ] So--the other year I asked for a few new backend features to make IMAP easier to implement. I wasn't quite on-the-ball enough to get it implemented in a timely manner, but the things are, nonetheless, there. Now that I've got an implementation going, I understand better what needs to be done to make this thing work well with Gnus and IMAP being the beasts they are. (And, well, having delved into the code, I'm better equipped to make patches if it comes to that. Scary code, though. ;>) The main thing that's slowing the nnimap backend down now is that IMAP and NNTP are capable of providing quite fundamentally different information. Our first example: In NNTP, the server knows nothing about you. All the server can tell the client is what messages exist. The client (Gnus) uses these numbers to figure out how many new messages you have by comparing them with what messages you've read. In IMAP, the server knows about your messages, and while Gnus knows some stuff, it doesn't know what messages you may've read with other (heretical) readers, say, on a Mac or something, because that's all you had to use. IMAP can tell you how many new messages you have--and that's fast, because it's just a count. It can also tell you what messages exist--but that's slow, because IMAP actually remembers message numbers as "UID"s, which aren't cached as well. (In addition, you have to select a mailbox in order to get the info about the first and last UIDs in the group.) On top of that, UIDs aren't necessarily allocated sequentially (although they're guaranteed to increase), so message counts aren't always right. In my mind, this calls for a backend method that would allow Gnus to say, instead of "What messages exist" "How many new messages?" and "How many total messages?" and the like. THis info is very quickly provided by IMAP. The group-info updating code is also a point that could be improved upon. This takes a LOOONG time when you're subbed to 50-200 groups. You have to select each group, do a query to find out which flags are on which messages, and then move on to the next group. (Group switching takes 1-2 seconds before the folder's well cached n the server.) I don't know how long the query takes--I haven't tried writing that yet, because I expect it to be really slow. Alongside the "how many new messages do you have", which takes a small amount of time, we could take the update-group-info method and call it only upon group entry. This way, we only have the cost of the query when the group is entered. It might take a few seconds (probably not more than two or so, since this is, again, fast info) to enter a group, but it will not, at least, take 400 seconds to update 200 groups all at once. With these changes: * add nnchoke-request-new-message-count * call nnchoke-request-update-info at group entry, not active-time I think nnimap can be quite efficient. I must admit that I have not looked at how the group-buffer generating code works, so I don't know how easy it would be to make it use a simple number instead of the newsrc and active stuff. The update-info stuff, I think, could easily be moved, or a different version of it could be created with a new name to be called in different places or something. Does anyone use this feature other than me? In any case--let me know what you think. Thanks, John.