From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50144 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: Sun, 16 Feb 2003 21:51:22 +0100 Organization: University of Duisburg, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84heb4x839.fsf@lucy.is.informatik.uni-duisburg.de> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045428666 3615 80.91.224.249 (16 Feb 2003 20:51:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 16 Feb 2003 20:51:06 +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 18kVka-0000vr-00 for ; Sun, 16 Feb 2003 21:51:01 +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 18kVm2-00068D-00; Sun, 16 Feb 2003 14:52:30 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 16 Feb 2003 14:53:29 -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 OAA14076 for ; Sun, 16 Feb 2003 14:53:15 -0600 (CST) Original-Received: (qmail 11331 invoked by alias); 16 Feb 2003 20:52:12 -0000 Original-Received: (qmail 11326 invoked from network); 16 Feb 2003 20:52:12 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by 66.230.238.6 with SMTP; 16 Feb 2003 20:52:12 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18kVxV-0000N8-00 for ; Sun, 16 Feb 2003 22:04:21 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 81 Original-NNTP-Posting-Host: p50877f29.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1045429461 1433 80.135.127.41 (16 Feb 2003 21:04:21 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 16 Feb 2003 21:04:21 GMT User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 Cancel-Lock: sha1:ZUcyntU7eaFq1e465HBU/CttJPU= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50144 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50144 Kevin Greiner 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? 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. 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