gnus-agent-cache is broken

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:
>>
>>> So, is anyone using the combination of gnus-agent being t but
>>> gnus-agent-cache being nil?
>>>
>>> I think now I agree with your suggestion of just removing the
>>> variable gnus-agent-cache.
>>
>> Making it possible to revert to old behaviour is IMHO always good, but
>> if it means alot of work maybe it can be removed...  the GNUS-NEWS
>> entry should be changed though:
>>
>> ,----
>> | ** Gnus reads the NOV and articles in the Agent if plugged.
>> |
>> | If one reads an article while plugged, and the article already exists
>> | in the Agent, it won't get downloaded once more.  (setq
>> | gnus-agent-cache nil) reverts to the old behavior.
>> `----
>>
>> OTOH, it doesn't sound like it would generate much work to call the
>> backend directly instead of looking at the cache directory of
>> gnus-agent-cache is null?
>
> If we did that, then setting gnus-agent-cache to null is identical to
> setting gnus-agent to null.
>
> As I read it, setting gnus-agent-cache to null will result in the
> agent always fetching headers and articles from the server that it
> then stores locally.
>
> Kai had a good point concerning performance. My thoughts were that
> this was a useful setting back when the agent wasn't that reliable.
> If you don't trust the agent, you might be willing to let it cache
> articles.  However, you would not want to depend on those cached
> articles when the server was available.
>
> What I need to do is stop talking and start testing.

OK, it failed my very first test.  I set gnus-agent-cache to nil then
opened a group.  All of the new headers were fetched as expected.
However, they were NOT stored in .overview.

I'll see what I can do to make it work.

Kevin