From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/6793 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Red GNUS suggestion: pseudo Xref: handling w/o NOV support. Date: 19 Jun 1996 01:58:49 -0400 Sender: sj@mindspring.com Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035147197 4756 80.91.224.250 (20 Oct 2002 20:53:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:53:17 +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 XAA29787 for ; Tue, 18 Jun 1996 23:44:47 -0700 Original-Received: from atreides.erehwon.org (sj@user-168-121-167-78.dialup.mindspring.com [168.121.167.78]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 19 Jun 1996 07:55:22 +0200 Original-Received: (from sj@localhost) by atreides.erehwon.org (8.7.5/8.7.3) id BAA00509; Wed, 19 Jun 1996 01:58:50 -0400 Original-To: ding@ifi.uio.no Original-Lines: 83 X-Mailer: Gnus v5.2.12/Emacs 19.31 Xref: main.gmane.org gmane.emacs.gnus.general:6793 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:6793 My news admin pointed out a good reason for not having Xref: full in their overview.fmt. The vast majority of their clients use PC-based readers and none of those readers support xref handling. In the course of the discussion, I had what I think is a good idea, but's I'm too sleepy to know for sure or to rewrite it. I'm just forwarding the post and hitting bed, you decide. :> Um, the last few paras are the main thing, the stuff about nntp-nov-is-evil and nntp-server-opened-hook would be nice, too. -Sudish ------- Start of forwarded message ------- From: Sudish Joseph Newsgroups: mindspring.discussion Subject: Re: Add XREF to mindspring's overview.fmt...pretty please? Date: 19 Jun 1996 01:42:26 -0400 Organization: MindSpring Enterprises Message-ID: References: <4q7rhm$2np@kaamos.mindspring.com> <4q810d$39b@kaamos.mindspring.com> Robert Sanders writes: > I've thought about enhancing GNUS 5.2 to keep a message ID database > for already seen crossposted articles. This isn't necessary, you could just grok the Xref: header and kill on article-id. GNUS does this if nntp-nov-is-evil is t. Or, it did, last time I fixed it. :-) What seems needed here is to do the above even when nntp-nov-is-evil is nil. Adding a small function to nntp-server-opened-hook that did a ``LIST overview.fmt'', checked for ``Xref: full'', and set a variable that was checked in addition to nntp-nov-is-evil for the above stuff is all that's needed. > The drawbacks are a) actually having to modify the GNUS code without > the benefit of intensive psychiatric care, Oh, rubbish. Lars's code is clean and fun to hack. > b) being somewhat otherwise occupied, No cure for that, unfortunately. :( > and c) emacs' lack of an efficient random access on-disk database > system. Saving, loading, and walking huge alists isn't my idea of > fast or fun. There's a patch that adds gdbm support to Emacs floating around. If you're really interested, I could dig up a reference. I believe Bill Perry's added this to XEmacs already--not sure if it's going to be in 19.14, though. There was some talk of adding an nngdbm backend to GNUS--it'd give all the benefits of nnml w/o the hit of large directory lookups. > If you're a patient man, setting gnus-nov-is-evil to 't' will solve > the problem, albeit in a painfully slow manner. All I can say is that > it's not terribly bad behind the office T1. Ugh. No thanks. :) Hmm, it just struck me. We already have all the message-id's for articles that we haven't read. All we have to do is generate a transient scorefile that lowered on those msg-ids. This wouldn't be slow for even large groups, scoring is very fast in GNUS. Heck, we wouldn't even have to write it to disk, the way GNUS already caches score entries (they're only read once per session, irrespective of your access pattern). This would be akin to how other xref-capable readers do this when xref info is available. Writing that file to disk is useless coz all concerned articles are already on your server, by definition. This would be a significant win, coz no other reader does this: crosspost handling w/o xrefs for unread articles. -Sudish ------- End of forwarded message -------