From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6425 Path: main.gmane.org!not-for-mail From: "Sudish Joseph" Newsgroups: gmane.emacs.gnus.general Subject: Re: Blue (or was it yellow?) GNUS suggestions Date: 28 May 1996 18:59:01 -0400 Sender: Message-ID: References: <199605252131.RAA00636@atreides> <199605280045.UAA00274@atreides> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146882 3546 80.91.224.250 (20 Oct 2002 20:48:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:48:02 +0000 (UTC) Cc: ding@ifi.uio.no 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 QAA22349 for ; Tue, 28 May 1996 16:38:37 -0700 Original-Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 29 May 1996 01:00:42 +0200 Original-Received: from ATLSER by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8255; Tue, 28 May 96 19:00:30 EDT Original-Received: by ATLSER (XAGENTA 4.0) id 5566; Tue, 28 May 1996 19:00:05 -0400 Original-Received: (from sj@localhost) by galaxy.atlissc.ibm.com (8.7.5/8.7.3) id SAA07303; Tue, 28 May 1996 18:59:02 -0400 Original-To: Lars Magne Ingebrigtsen In-Reply-To: Lars Magne Ingebrigtsen's message of 28 May 1996 21:52:11 +0200 Original-Lines: 68 X-Mailer: September Gnus v0.78/Emacs 19.31 Xref: main.gmane.org gmane.emacs.gnus.general:6425 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6425 Lars Magne Ingebrigtsen writes: > Sudish Joseph writes: > > a loop that checks the buffer associated with the NNTP connection, > > sees if any new headers have arrived, slurps all new headers in a > > list, generates/updates current threads/summary info for that > > list, then loops back to check the nntp buffer, etc. > > That sounds very complicated. And is it useful? How many new > articles typically arrive for the group you're reading while you're > reading the group? No, I was rambling about doing this for _every single_ header. Well, clumps of headers, where clump is defined as all headers in the *nntp* buffer at the time you get to the end of the the buffer. On a fast link, you'd get the same behaviour as today, since more headers would arrive in the time GNUS finished inspecting the ones that were there. On a slow link, GNUS could get a hell of a lot done in the time it sat waiting for _all_ the headers to arrive. But yeah, it'd be very complex. Just figuring out how to let the user select an article in the midst of the above loop would be pain enough for anyone. > I don't quite see how Gnus would be helped by this. The way Gnus > threads things is highly user-customizable (gathering, fuzzy subject > comparison, sparse nodes, ancient articles, ad nauseam). If we had a > separate process spewing out the threads at us, then we'd lose that > Lispish extensibility. Well, that's why the format of the thread info becomes important. It should be general enough to support all that and more :-) Um, fuzzy subjects are a sorting issue, imho. If INN was maintaining this info, one can imagine stuff like "gimme the roots of all threads rooted in articles that arrived after article n", etc. > Anyways, the threading itself is no problem. The most time spent is > used to generate the summary buffer, and there no external process can > help us. Ugh, clarity was never my strong suite. Here's another attempt. Currently all events that occur the summary generation process have to wait upon the arrival of _all requested headers_. IMO, it'd be a big win if GNUS went ahead and prepared the summary for the headers it already has, thus distributing the cost of summary generation over the time wasted waiting for all headers. Obviously, this is not a big win if you're sitting on a fast, unsaturated network--there's a saturated token ring here at work where it'd help, though :)--but it won't be a loss either. It would also improve the responsiveness of GNUS for all users, since you'd be dropped into a summary buffer almost as soon as you selected the group. To get this for people on a fast network, we'd have to add some crock like always grabbing the first n headers (n being small) and generating a summary using those before going back to what I outline above. This would be a _huge_ win for people on dialup links, and mostly irrelevant for people with a network card (well, the improvement in responsiveness would help them, too). But, like you said, it'd be a pain to code/maintain. -Sudish