Re: Excessive nntp reads since today

[Tassilo Horn <tassilo@member.fsf.org>]

Wolfgang Jenkner <wjenkner@inode.at> writes:

Hi Wolfgang,

>>   - The old and buggy 'some semantics of `gnus-fetch-old-headers'
>>     were exactly what I want.  I.e., I want Gnus to *fetch* only new
>>     messages, but it should also *display* summary lines of old
>>     messages to fill loose threads in case those can be determined from
>>     the overview.
>
> IIUC, the summary would consist of new headers and some subset of the
> headers cached by the agent.

Yes, exactly.

> I think this is a problem because the agent cache seems to be designed
> to be transparently used, so that you have always the illusion of
> talking directly to the server.  When the agent is plugged, that is.
> However, when the agent is unplugged, the agent is your server, in
> some sense.  So I think you can have what you want in the following
> clean way:
>
> Get new articles, fetch them with the agent, unplug, enter a group.
>
> g J s J j . RET

Yes, that would probably work.  However, that would be extremely
inconvenient.  And as soon as I forget to unplug the agent when entering
a group, the agent would see that my .overview files start with article
382832 instead of 1 and start downloading the headers of the old 382831
ones.  That's simply not feasible for large groups, e.g., all the emacs
and gnus groups on gmane which are never expired and thus contain
millions of articles.

> For this to work, it seems necessary to set gnus-fetch-old-headers to
> t instead of some (but I might have wrong expectations or
> misunderstand something here, and, obviously, I haven't tested this
> very extensively).

I think t and 'some are the same with respect to the agent.  And it gets
the value only as parameter but never accesses the variable directly.

Lars, what do you think?

IMHO, the best cure is to remove `gnus-fetch-old-headers' altogether and
add a `gnus-summary-show-old-articles' variable that only deals with the
summary display stuff.  Values would be t (show all), nil (only unread),
or 'some (some old to connect lose threads), or a number (show unread +
N old).

How many old articles are fetched at most in the `A T' case is handled
by `gnus-refer-thread-limit' anyway.  I'm not sure if C-u 1000 RET on a
group would still fetch (- 1000 |cached| |unread|) old articles,
though...

The only difference to the current state of affairs would be that t or
'some for `gnus-summary-show-old-articles' would only show already
fetched articles.  Thus, when subscribing to some new group, catching
up, getting new news again, entering the group, you'd possibly have
unconnected articles initially, but that would go away over time when
the overview files get filled unless very old messages are referenced.
Of course, all of this requires a nil `gnus-nov-is-evil', but that has
always been the case, right?

And I think it would be equivalent to the old behavior before your
commit, except that the documentation and the name of the variable would
actually match the behavior. :-)

Bye,
Tassilo