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

[Sudish Joseph <sudish@mindspring.com>]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Sudish Joseph <sudish@mindspring.com> writes:
> > 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.=20
> 
> That might be a good reason if not for a slight niggle:  It's
> bullshit.  Most modern newsreaders that run under MicroSloth
> "operating systems" use the Xref header.  (At least that's what I've
> been told.)

I did a dejanews search on 'xref add' (using "performance" as a
keyword was a lose) over news.software.* before I accepted that
statement (remember, I was the one wanting xref :-).  Most hits fit one
of 3 classes:  a) INN/NOV faq :-)  b) Suggestions that xref be added
w/o any performance analysis  c) Statements to the effect that no PC
readers support xref, so why should J. Random Sysop add it.  

> Even if it were true -- so what?  Adding Xref to the NOV databases
> doesn't hurt newsreaders that don't make use of the information.  So
> not adding Xref to the databases is rather, uhm.  Let me stop there
> before I get nailed by CDA=B2 (coming soon to an Internet near you).

This was more or less my argument.  The newsdmin pointed out that
there will be a hit in download time due to the extra size of the
xover data.  The comment about "most PC readers" was in response to me
pointing out that an xref-capable reader will download less headers
and thus save space, which blew away my argument.  He put it rather
well: from the pov of an ISP, one of the more important selling points
is "headers download faster".

Hey, I fought the good fight, stop making me feel guilty. :)

> > 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.
> 
> This is a very good idea.  Actually, we don't even have to use
> scoring.  We just add the Message-IDs to the NoCeM hashtable, which
> will efficiently censor all articles that we have already read.

Maybe move the hashtb funcs into nnoo or something?  A new user might
well not enable NoCeM support (or those suckers who, like me, cannot
use a free US-released PGP in the US w/o residency, and cannot import
a non-US version into the US--has this changed, anyone?)  Not a big
deal, though.

Also, what do you think about adding a adding a test of overview.fmt
to nntp-server-opened-hook?  I think there's a good idea there.  Why
not have a probe function that sent XOVER, etc., to the server and
determined the optimal config for nntp reading?  Running this every
time seems bogus...maybe a nntp-suggest-kewl-config command?  There
aren't very many critical variables to setup here and it might reduce
the size of the oh-so-neat-FAQ that Steve Baur has blessed us with.
This would let people who have no wish to ever know the meaning of the
word XOVER have a decent shot of acheiving their goal. :-)

> The drawback here is (of course) that such an approach wouldn't work
> if you read one article in one session and the other copy of the
> article in another session.  We could write the list of Message-IDs
> already seen to a file, but that file would grow rather big...

Yeah, writing that out to a file seems yucky.  How about running that
scorefile/hashtb over all groups when quitting GNUS?

-Sudish