From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6385 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Blue (or was it yellow?) GNUS suggestions Date: Sat, 25 May 1996 17:31:54 -0400 Message-ID: <199605252131.RAA00636@atreides> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035146848 3444 80.91.224.250 (20 Oct 2002 20:47:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:47:28 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id PAA27641 for ; Sat, 25 May 1996 15:01:51 -0700 Original-Received: from atreides (sj@atl-ga9-06.ix.netcom.com [199.183.210.102]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 25 May 1996 23:28:58 +0200 Original-Received: (from sj@localhost) by atreides (8.7.5/8.6.9) id RAA00636; Sat, 25 May 1996 17:31:54 -0400 Original-To: ding@ifi.uio.no X-Mailer: VM 5.95 (beta), GNU Emacs 19.30.2 Xref: main.gmane.org gmane.emacs.gnus.general:6385 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6385 I'm now setup at home with a 28.8 link and Linux. So, all sorts of bandwidth-related ideas now occur to me (read: netcom's lines suck :-) * Caching the list of newsgroups locally. Setting gnus-read-active-file to 'some solves the speed problem in the most common case (startup), but it makes it very painful to subscribe to new/boring-until-now groups. Setting gnus-save-killed-list to 't solves this, but makes exit very slow. I guess what I'm asking is if it's possible to split the killed list from the .eld file, so that it's not necessary to read and write such a large chunk of data every session. Viewing it as a reduced (w/o article ranges) local copy of the active file might be better than just calling it a killed list. Updating this cache when we see new groups (gnus-check-new-newsgroups is 'ask-server, of course) would keep things very neat. * Defering splitting of mail in nnml groups to group entry. This isn't related to bandwidth in any way, but I might as well bring it up here. The actual speed hit in nnml is in the writing of the articles to individual files, not in the nov file generation. So, just spooling all articles to one file per nnml group that would be split into separate files upon group selection would be neat. This would still allow for nov generation at split time. At OSU, I was on the perl-porters mailing list, a very high-volume list. I mention OSU only because our NFS setup sucked so hard speedwise. Which meant that I had to sit through a long split session for that one list every time I fired up gnus, even though I read that list once a week or so. This was one of the main reasons I stuck with asynchronous mail delivery. I think this, or having nnfolder with nov, would be a very cool option for people with NFS mounted home directories. Note that there isn't much difference between what I describe above and having nnfolder use nov--the only difference is that we do an extra split at group entry time. Now that I have a local ext2 filesys to spool to, asynch splitting isn't worth the trouble to me and I also get to use sexps to describe my splitting, instead of procmails tortuous syntax, but I think it's important that GNUS makes things better for people with slow writes to their home directory--which covers a lot of people in larger universities, I'd say. * Prefetching of articles in the next group. The nntp-async stuff is a real godsend for dialup lines--once you've waited for that first article, subsequent articles are quick to select. It'd be nice to extend this to work across group boundaries. Also, I think the current async stuff doesn't handle the case where you go back and read an earlier article in the group too well. Even though that article is in the async buffer, it seems to refetch it. * Some way to force GNUS to drop all active tcp connections to the NNTP server and open them anew. I'm using diald to manage my connections. While gnus uses a fresh connection for articles in a group, it maintains the "control" connection (the connection used for switching groups, etc.). This means that if diald drops my line due to inactivity and then fires it up again, the control connection is invalid since I have a new IP address. A command in the group buffer to force GNUS to re-open the control connection, while maintaining current state info, would be very useful. I'm not suggesting we go to the extreme of http, reusing existing connections is much better, IMO, except when the connection itself is invalid (there's no way for gnus to determine when the connection is invalid, so it has to be a user command). * Incremental/asynchronous group entry. This one is much harder, and probably should be left until Lars has cycled through all the colors in the rainbow :-) It has also been discussed before. Presently, upon entering a large group, I wait for a longish bit as the headers get sucked in (all hail the great god XOVER, without whose intervention life would be a void) and then for a shorter, but still significant, period while gnus prepares the summary. Incremental threading and summary generation (ugly thought, but GNUS does most of the required magic already when you fetch a parent article) would make a huge difference. As I see it, the only real obstacle here is in the thread and sorting code--sorting thread roots while _incrementaly updating_ threads seems difficult to me. I would happily forgo sorting if I could hit SPC on a newsgroup and enter it immediately. This won't be such an attractive option for peple with bad newsfeeds, since article numbers will be badly skewed w.r.t posting date (IBM's newsfeed often gets articles 14-15 days after they're posted, this makes sorting by date a necessity :( ). I'm willing to bet that quite a few would prefer faster group entry to sorting. Netscape does asynchronous threading, if you haven't checked it out. -- Sudish