Re: nnchoke-retrieve-groups and nnchoke-request-group

[Greg Stark <gsstark@MIT.EDU>]

Lars Magne Ingebrigtsen <larsi@gnus.org> 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.