From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50159 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap usage model Date: Tue, 18 Feb 2003 08:22:55 -0600 Sender: owner-ding@hpc.uh.edu Message-ID: References: <84heb4x839.fsf@lucy.is.informatik.uni-duisburg.de> <84n0ku7u6n.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1045578156 4106 80.91.224.249 (18 Feb 2003 14:22:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 18 Feb 2003 14:22:36 +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 18l8dm-000143-00 for ; Tue, 18 Feb 2003 15:22:34 +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 18l8eX-0006A6-00; Tue, 18 Feb 2003 08:23:21 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 18 Feb 2003 08:24:19 -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 IAA18387 for ; Tue, 18 Feb 2003 08:24:03 -0600 (CST) Original-Received: (qmail 94521 invoked by alias); 18 Feb 2003 14:23:01 -0000 Original-Received: (qmail 94516 invoked from network); 18 Feb 2003 14:23:01 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by 66.230.238.6 with SMTP; 18 Feb 2003 14:23:01 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18l8qk-0006wY-00 for ; Tue, 18 Feb 2003 15:35:58 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 111 Original-NNTP-Posting-Host: 35.0012159.lodgenet.net Original-X-Trace: quimby.gnus.org 1045578958 26693 12.18.119.35 (18 Feb 2003 14:35:58 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 18 Feb 2003 14:35:58 GMT User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.2 Cancel-Lock: sha1:RL/+DjAiE0zEhNJm3r6DejCUqLg= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50159 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50159 kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: > 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. 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