Red GNUS suggestion: pseudo Xref: handling w/o NOV support.

[Sudish Joseph <sudish@mindspring.com>]

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 <sudish@mindspring.com>
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: <m2rarcqri5.fsf@atreides.erehwon.org>
References: <m2688oslv1.fsf@atreides.erehwon.org>
	<4q7rhm$2np@kaamos.mindspring.com>
	<m2vigoqw7b.fsf@atreides.erehwon.org>
	<4q810d$39b@kaamos.mindspring.com>
	<knyblkgyu3.fsf@xena.mindspring.com>

Robert Sanders <rsanders@mindspring.net> 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 -------