Gnus development mailing list
 help / color / mirror / Atom feed
From: Sudish Joseph <sudish@mindspring.com>
Subject: Re: NoCeM flakiness in 0.74 and higher
Date: 17 Dec 1996 15:53:13 -0500	[thread overview]
Message-ID: <yviaohfsq4ee.fsf@atreides.mindspring.com> (raw)
In-Reply-To: Lars Magne Ingebrigtsen's message of 17 Dec 1996 20:16:36 +0100

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Can't you just remove a.n.m from `gnus-nocem-groups'?

I did.  But from what I posted, isn't it indicative of a (pretty
scary) bug?  Namely that gnus has lost track of what articles it has
already seen.

>> In particular, it'd be neat if one could have an alist that let you
>> specify the type of score entry you want generated for articles
>> that're being eliminated by nocem.  A followup entry (I.e., low score
>> on references) would be the most useful.

> Yes, that would be useful.  It might be tricky to implement in an
> efficient fashion, though.

It could as simple as providing a variable, gnus-nocem-scorefile.  If
non-nil, nocem handling in done via score files.  Instead of inserting
msg-id's in News/NoCeM/cache, insert a "followup" entry in this
scorefile.  

The user is free to have that scorefile used in whatever groups they
see fit, using any of the many options gnus provides.  I, for example,
would add a 'files entry for it in all.SCORE.

The nice thing of doing it this way is that I can run a -batch nocem
process w/o ever having to worry about coming up with lightweight
locking for NoCeM/active.  Do a score file cache flush and you have
the latest scorefile.

Of course, if the user ever decides to use that scorefile in another
context, all bets are off.  

Hmm, to address David's worry about the size of the resulting
scorefile: if this method remains as simple as only allowing score
entries of one type (it might be followup or subject, but fixed), we
can even do it w/o changing the format of NoCeM/active.

We'd need to add some form of score-file handler hook that lets us
treat that file as a normal scorefile and massage it's data into
normal score format at the time it gets read into the score cache --
not hard or time intensive, each entry is of the same format.  Note
that not treating it as a scorefile would mean all types of kluges to
allow concurrent -batch access and would be a lose, IMO.

Enough fantasizing for today.
Later,
-Sudish


  parent reply	other threads:[~1996-12-17 20:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-12-17 18:36 Sudish Joseph
1996-12-17 19:16 ` Lars Magne Ingebrigtsen
1996-12-17 20:28   ` David Moore
1996-12-17 20:53   ` Sudish Joseph [this message]
1996-12-17 19:36 ` David Moore
1996-12-17 21:13   ` Sudish Joseph
1996-12-17 22:35     ` David Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yviaohfsq4ee.fsf@atreides.mindspring.com \
    --to=sudish@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).