From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50154 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap usage model Date: Mon, 17 Feb 2003 17:23:12 +0100 Organization: University of Duisburg, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84n0ku7u6n.fsf@lucy.is.informatik.uni-duisburg.de> References: <84heb4x839.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045498977 22156 80.91.224.249 (17 Feb 2003 16:22:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2003 16:22:57 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18ko2d-0005kW-00 for ; Mon, 17 Feb 2003 17:22:51 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18ko49-0002of-00; Mon, 17 Feb 2003 10:24:25 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 17 Feb 2003 10:25:22 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id KAA16366 for ; Mon, 17 Feb 2003 10:25:06 -0600 (CST) Original-Received: (qmail 48605 invoked by alias); 17 Feb 2003 16:24:04 -0000 Original-Received: (qmail 48600 invoked from network); 17 Feb 2003 16:24:04 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by 66.230.238.6 with SMTP; 17 Feb 2003 16:24:04 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18koFt-0002tH-00 for ; Mon, 17 Feb 2003 17:36:33 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 101 Original-NNTP-Posting-Host: lucy.is.informatik.uni-duisburg.de Original-X-Trace: quimby.gnus.org 1045499793 11114 134.91.35.216 (17 Feb 2003 16:36:33 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 17 Feb 2003 16:36:33 GMT User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 Cancel-Lock: sha1:tJCrlIU6dnFN8cWsB6YnxTvqZGs= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50154 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50154 Kevin Greiner 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