Re: nnimap usage model

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Kevin Greiner <kgreiner@xpediantsolutions.com> writes:
>
>>   When Gnus is plugged, it is not efficient to download headers or
>>   articles from the server again, if they are already stored in the
>>   Agent.  So, Gnus normally only downloads headers once, and stores them
>>   in the Agent.  These headers are later used when generating the
>>   summary buffer, regardless of whether you are plugged or unplugged.
>>   Articles are not cached in the Agent by default though (that would
>>   potentially consume lots of disk space), but if you have already
>>   downloaded an article into the Agent, Gnus will not download the
>>   article from the server again but use the locally stored copy instead.
>>   
>>   This behaviour can be controlled by `gnus-agent-cache' (*Note Agent
>>   Variables::).
>>
>> English is my first language and I admittedly had to read this twice.
>
> Well said.  :-)
>
> Is the following correct?  Or rather, which parts of it are wrong?
>
> Originally, the Agent was intended for offline reading: you download
> headers and/or articles and then go offline and then Gnus uses the
> locally stored data.  However, it turns out that the Agent is useful
> even while you're online: it is usually faster to read headers and
> articles from the local disk rather than from the network.
> In that case, it's obviously useful to have some data on the local
> disk in the first place.  But you don't want to have too much data on
> the local disk, lest it burst.  So, what's a Gnus to do?
>
> It turns out that the Gnus Towers decided that the following
> compromise would be right for you.  However, Gnus is Gnus and thus
> it goes without saying that you can configure this default behavior.
>
> So, say that you enter a group and hence Gnus downloads the headers
> for this group.  The default behavior is to store the headers locally.
> So when you enter the group later on, the old headers can be fetched
> from the local disk, and only the new headers have to be downloaded.
> Good.  So what about articles?  Well, if an article happens to be on
> the local disk already, Gnus will not fetch it from the network again
> and instead use the local copy.  But on the other hand, Gnus does not
> by default store every article you read on the local disk, as that
> might consume too much disk space.
>
> The previous description holds when the variable `gnus-agent-cache'
> is non-nil, which is the default.  (*Note Agent Variables::).
>
> If `gnus-agent-cache' is nil, then Gnus will not store headers or
> articles locally, and it will not read locally stored headers or
> articles.
>
>     CCC: Kevin, Simon, is the previous paragraph correct?

It's true so how does gnus-agent-cache differ from gnus-agent? hmmm,
see following...

When I search the code, I find that gnus-agent-cache always appears in
an AND expression, "(and gnus-agent gnus-agent-cache ...", that also
requires that gnus-agent be set.  The specific functions, as you
implied, where it is found are:

gnus-request-article-this-buffer
gnus-retrieve-headers
gnus-request-head
gnus-request-body
gnus-request-expire-articles
gnus-request-move-article

Checking further, the function gnus-agent-retrieve-headers is the only
function to bind gnus-agent-cache to nil.  This explains why the
original definition was somewhat accurate.  It also points out that
most of the functions checking gnus-agent-cache
(i.e. gnus-request-article-this-buffer, gnus-request-body,
gnus-request-expire-articles, and gnus-request-move-articles) should
NOT do so.  The only function called while gnus-agent-cache is bound
to nil is gnus-retrieve-headers.  That function performs an AND of
gnus-agent and gnus-agent-cache so binding either to nil would have
the same result.

I'd say that the proper thing to do is to replace gnus-agent-cache
with gnus-agent in gnus-agent-retrieve-headers (i.e. bind gnus-agent
to nil) then delete gnus-agent-cache at all other references.

If you really want to implement the original definition, then we'd
need to make several changes.  For headers, it would look something
like this: 
The function gnus-retrieve-headers would, if gnus-agent is
set, call gnus-agent-retrieve-headers which would, if gnus-agent-cache
is set or gnus-plugged is nil, use the local cache.  Otherwise,
gnus-agent-retrieve-headers would use the backend to retrieve the
headers then store them in the local cache.

As I see it, the only advantage to having gnus-agent-cache is to
handle the case in which the article keeps changing on the server.
Does that actually happen with any of the backends?



>
> Above, it was said that articles are not automatically stored locally
> when you read them, while Gnus is plugged.  But what if I have a big
> disk, you cry.  Don't worry!  You can use one of the following two
> lines in ~/.emacs or ~/.gnus:
>
>     (add-hook 'gnus-select-article-hook 'gnus-agent-fetch-selected-article)
>     (add-hook 'gnus-mark-article-hook 'gnus-agent-fetch-selected-article)
>
> It does not make sense to use both lines.  The difference between the
> two lines is subtle.  The first line says, whenever you select an
> article for reading, Gnus looks if it is on disk already, and if no,
> then it is stored.  The second line says that Gnus only looks when you
> select the article for the first time.

I'd change "The second line says that Gnus only looks when you select
the article for the first time." to "The second line says that Gnus
will fetch new articles to the local disk as the summary buffer is
opened.".

>
>     CCC: Anyone, did I get the subtle difference right?  I kind of
>     doubt it.  It's so subtle...
>
> ***
>
> OK.  So much for the stuff that could be in that node of the info
> file.  Now we need a better description of the variable
> gnus-agent-cache.  I think the current description in `Agent
> Variables' is misleading.  According to the description there, only
> the reading is affected.  But I guess that also the storing of the
> NOV data is affected.  Anyone?
>
> -- 
> A turnip curses Elvis

Kevin