From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/11019 Path: main.gmane.org!not-for-mail From: Greg Stark Newsgroups: gmane.emacs.gnus.general Subject: Re: nnchoke-retrieve-groups and nnchoke-request-group Date: 21 May 1997 17:29:30 -0400 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035150799 27811 80.91.224.250 (20 Oct 2002 21:53:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:53:19 +0000 (UTC) Return-Path: Original-Received: from sandy.calag.com (root@sandy [206.190.83.128]) by altair.xemacs.org (8.8.5/8.8.5) with ESMTP id QAA19219 for ; Wed, 21 May 1997 16:29:49 -0700 Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by sandy.calag.com (8.8.5/8.8.5) with ESMTP id QAA20508 for ; Wed, 21 May 1997 16:29:28 -0700 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with SMTP id SAA28567 for ; Wed, 21 May 1997 18:28:42 -0500 (CDT) Original-Received: from claymore.vcinet.com (claymore.vcinet.com [208.205.12.23]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Wed, 21 May 1997 23:58:30 +0200 Original-Received: (qmail 8361 invoked by uid 504); 21 May 1997 21:58:28 -0000 Original-Received: (qmail 8358 invoked from network); 21 May 1997 21:58:25 -0000 Original-Received: from g62-76.citenet.net (brnstnd@kramden.acf.nyu.edu@207.183.46.76) by claymore.vcinet.com with SMTP; 21 May 1997 21:58:25 -0000 Original-Received: by g62-76.citenet.net id m0wUIwu-0008eZC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 21 May 1997 17:29:32 -0400 (EDT) Original-To: ding@gnus.org In-Reply-To: Lars Magne Ingebrigtsen's message of 19 May 1997 02:21:00 +0200 X-Mailer: Gnus v5.4.52/Emacs 19.34 Original-Lines: 60 Original-Xref: altair.xemacs.org dgnus-list:1405 Xref: main.gmane.org gmane.emacs.gnus.general:11019 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:11019 Lars Magne Ingebrigtsen writes: > Yes. So the solution is to kill off all the groups you aren't > interested in and using `some'. Well that's hardly a solution. Let me explain what i did, what i was trying to accomplish and what Gnus actually did: I read groups from various backends including nnfolder, nntp, and nndsc (the one i wrote for dealing with a network news-like system called discuss). I'm behind a slow PPP link so i want to minimize the amount of network traffic Gnus needs to do just to get started. To this end i set the levels of most of my nnfolder groups to level 2, the nntp and nndsc groups i often read to 4 and the groups i rarely if ever read to 5. Then i set gnus-activate-level and gnus-activate-foreign-newsgroups to 3. I expected that to make M-x gnus only fetch information about the few level 2 groups all of which are nnfolder groups. And when i want to read the other groups i read i can do C-u 4 g to activate those groups. And I expected Gnus to never bother getting information on the hundreds of groups at level 5 that i only skim through on rare occasions. But that's not how it seems to work out. M-x gnus causes gnus to open the nntp server even though not a single nntp group is level 2 or 3. And C-u 4 g doesn't cause gnus to actually activate the level 3 groups, or even open the nndsc server on which some of the level 4 groups are. Furthermore, if i have gnus-read-active-file set to 'some then gnus reads active file information on all the groups level 7 and below it just throws that information away. I want to have those hundreds of groups at level 5 available, and i want gnus to keep track of read ticked articles etc. so killing them isn't appropriate, but i don't want every time i start up gnus to have to wait while gnus reads the active file information for them. And I dont want to set gnus-read-active-file to nil because it's so much less inefficient (in particular for the nndsc server where it defeats a speed optimization i can only do for retrieve-groups style batch queries). Ideally gnus wouldn't even open the nntp server at all unless i was starting it at a level high enough to include at least one nntp group. That might be hard, but at the very least i would expect C-u 4 g to activate the groups level 4 and lower and only to fetch active file information on those groups, not any higher level groups. greg PS It's somewhat unfortunate that M-g doesn't sound like it will ever be able to do what i want (batch all the groups into a retrieve-groups style request). I'm not really concerned with the semantic difference between the two queries that sounds nntp-specific, that the active file can differ and be out of date compared to the request-group query information. If that is the only problem then you should just add a flag argument to the retrieve-groups query to indicate it needs the most up-to-date info and if nntp.el needs to use a different query to satisfy that that's fine. Other backends are unlikely to make such a disinction and it's silly to restrict the interface between Gnus and the backends to an inefficient interface because of it. But it sounds like it would also be difficult with the current organization of the code. I'll look at it myself, but if C-u 4 g and C-u 3 g only queried about the groups they really needed M-g being inefficient wouldn't really bother me as much.