Re: nnimap usage model

[kai.grossjohann@uni-duisburg.de (Kai Großjohann)]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> 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?

Now I'm more confused than before.

Often, gnus-agent and gnus-agent-cache are mentioned together.  There
is one spot that you have identified where gnus-agent-cache is
mentioned without gnus-agent.

There are also just a couple of spots where gnus-agent is mentioned
without gnus-agent-cache: (1) On sending a message, the Gcc processing
is different depending on gnus-agent.  (2) gnus-get-unread-articles
tells the agent to save the active file, if gnus-agent is non-nil.
(3) gnus-active-to-gnus-format does the same.

Hm.  Oh, I forgot to search for "gnus-agent$".  That finds more
spots.  (1) gnus-group-get-new-news-this-group tells the agent to
save the group info.  (2) gnus-get-function calls gnus-agent
functions instead of nnchoke functions.  (3) gnus-open-server does
stuff.  ...  And other stuff.

So, to summarize:

* Turning on gnus-agent enables a lot of special behavior, even if
  gnus-agent-cache is off.

* Turning on both gnus-agent and gnus-agent-cache enables more
  special behavior.

* Turning on gnus-agent-cache enables 1 piece of strange
  functionality, even if gnus-agent is off.  This is arguably a bug.
  Hm.  Hmmm...  No, the let-binding that you're talking about is
  something else entirely.

I think what we want is this:

* If gnus-agent is off, then the value of gnus-agent-cache doesn't
  matter.

* If gnus-agent is on, then it's possible to also turn on
  gnus-agent-cache to enable more special behavior.


It seems there is a misunderstanding.  I'm looking at things from the
user's perspective.  For this case, I think the questions we need to
answer are the following:

(1) Under which circumstances does the agent write data to the local
    disk?  Which data does it write?

(2) Under which circumstances does the agent read data from the local
    disk?  Which data does it read?

Then we can formulate some documentation that helps the user.

Another issue is whether the current Gnus behavior is correct or
should it be changed.
-- 
A turnip curses Elvis