Re: nnimap usage model

[Kevin Greiner <kgreiner@xpediantsolutions.com>]

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

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

I don't see these as being separate issues.  If the current
implementation is broken, and no one has noticed, then the feature
must not be in wide spread use.  If it isn't used, do we document how
we think it should work (then fix the implementation) or do we remove
the feature from the documentation?  On the other hand, if the current
implementation is working, how can we document it correctly if we
can't agree on what it is doing?

Kevin