From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/81960 Path: news.gmane.org!not-for-mail From: Wolfgang Jenkner Newsgroups: gmane.emacs.gnus.general Subject: Re: Excessive nntp reads since today Date: Sat, 16 Jun 2012 16:18:42 +0200 Message-ID: <858vfne3wd.fsf@iznogoud.viz> References: <877gvcd91f.fsf@thinkpad.tsdh.de> <85txygk74a.fsf@iznogoud.viz> <87y5nsbqj4.fsf@thinkpad.tsdh.de> <85pq94k37p.fsf@iznogoud.viz> <87aa08big2.fsf@thinkpad.tsdh.de> <85vcivuxmf.fsf@iznogoud.viz> <87haufw88y.fsf@thinkpad.tsdh.de> <85r4tjcgox.fsf@iznogoud.viz> <87zk87t4za.fsf@thinkpad.tsdh.de> <85oboja3nn.fsf@iznogoud.viz> <87k3z7bep9.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1339856410 10651 80.91.229.3 (16 Jun 2012 14:20:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2012 14:20:10 +0000 (UTC) Cc: ding@gnus.org, Lars Magne Ingebrigtsen To: Tassilo Horn Original-X-From: ding-owner+M30230@lists.math.uh.edu Sat Jun 16 16:20:09 2012 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SftrE-0006dJ-Sh for ding-account@gmane.org; Sat, 16 Jun 2012 16:20:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Sftq5-0001w5-Ou; Sat, 16 Jun 2012 09:18:57 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Sftq4-0001vp-2z for ding@lists.math.uh.edu; Sat, 16 Jun 2012 09:18:56 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sftq0-0006ST-F6 for ding@lists.math.uh.edu; Sat, 16 Jun 2012 09:18:53 -0500 Original-Received: from mx04.lb01.inode.at ([62.99.145.4] helo=mx.inode.at) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Sftpy-00032r-CR; Sat, 16 Jun 2012 16:18:50 +0200 Original-Received: from [91.119.143.36] (port=7547 helo=iznogoud.viz) by smartmx-04.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Sftpt-00054t-9O; Sat, 16 Jun 2012 16:18:45 +0200 Original-Received: from wolfgang by iznogoud.viz with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sftpq-0000Ux-Nd; Sat, 16 Jun 2012 16:18:42 +0200 Mail-Followup-To: Tassilo Horn , ding@gnus.org, Lars Magne Ingebrigtsen In-Reply-To: <87k3z7bep9.fsf@thinkpad.tsdh.de> (Tassilo Horn's message of "Sat, 16 Jun 2012 14:53:38 +0200") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (berkeley-unix) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:81960 Archived-At: On Sat, Jun 16 2012, Tassilo Horn wrote: > Wolfgang Jenkner writes: > >>>> Well, as I said, when plugged the agent cache is, IMHO, designed to >>>> be transparent with respect to the server. >>>> >>>> This implies that the summary should be the same as if the agent >>>> were non used at all. >>>> >>>> Only when the agent is unplugged it effectively is the server and >>>> you may expose its internal state in the summary. >> >>> Thus there shouldn't be a need to have subscribed groups to be >>> complete (header) mirrors of all available messages on the server. >> >> Of course not. Nobody said that the agent should cache all headers. >> >> Quite the contrary, actually :-) > > But that's actually the effect of your patch. If the fetch-old argument > is something not numerical, it'll fetch all headers starting with > article number 1 and cache them in the .overview. And that's consistent with the principles I humbly think the agent is based upon and which I stated above. Now, it's quite possible that these principles exist only in my imagination or that the convenience of making an exception and handling the case fetch-old=some specially would outweigh the resulting conceptual inconsistency. Please note, however, that not only the "bad new" behaviour has been documented since at least 2005 but also that Kevin Greiner, who rewrote a lot of the agent stuff, actually significantly clarified the meaning of `some' as value of gnus-fetch-old-headers on 2005-11-20 [*]. Wolfgang [*] Here's the diff: diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el index dfc3c09..9df8131 100644 --- a/lisp/gnus-sum.el +++ b/lisp/gnus-sum.el @@ -63,17 +63,21 @@ it will be killed sometime later." (defcustom gnus-fetch-old-headers nil "*Non-nil means that Gnus will try to build threads by grabbing old headers. -If an unread article in the group refers to an older, already read (or -just marked as read) article, the old article will not normally be -displayed in the Summary buffer. If this variable is t, Gnus -will attempt to grab the headers to the old articles, and thereby -build complete threads. If it has the value `some', only enough -headers to connect otherwise loose threads will be displayed. This -variable can also be a number. In that case, no more than that number -of old headers will be fetched. If it has the value `invisible', all +If an unread article in the group refers to an older, already +read (or just marked as read) article, the old article will not +normally be displayed in the Summary buffer. If this variable is +t, Gnus will attempt to grab the headers to the old articles, and +thereby build complete threads. If it has the value `some', all +old headers will be fetched but only enough headers to connect +otherwise loose threads will be displayed. This variable can +also be a number. In that case, no more than that number of old +headers will be fetched. If it has the value `invisible', all old headers will be fetched, but none will be displayed. -The server has to support NOV for any of this to work." +The server has to support NOV for any of this to work. + +This feature can seriously impact performance it ignores all +locally cached header entries." :group 'gnus-thread :type '(choice (const :tag "off" nil) (const :tag "on" t)