From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37656 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap - not quite there yet? Date: Thu, 09 Aug 2001 23:52:09 +0200 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1035173030 14968 80.91.224.250 (21 Oct 2002 04:03:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:03:50 +0000 (UTC) Cc: ding-list Return-Path: Return-Path: Original-Received: (qmail 27669 invoked from network); 9 Aug 2001 21:52:46 -0000 Original-Received: from waldorf.cs.uni-dortmund.de (129.217.4.42) by gnus.org with SMTP; 9 Aug 2001 21:52:46 -0000 Original-Received: from lothlorien.cs.uni-dortmund.de (lothlorien.cs.uni-dortmund.de [129.217.19.67]) by waldorf.cs.uni-dortmund.de with ESMTP id XAA03974; Thu, 9 Aug 2001 23:52:10 +0200 (MES) Original-Received: from lucy.cs.uni-dortmund.de (lucy [129.217.19.80]) by lothlorien.cs.uni-dortmund.de id XAA25107; Thu, 9 Aug 2001 23:52:09 +0200 (MET DST) Original-Received: (from grossjoh@localhost) by lucy.cs.uni-dortmund.de (8.9.3/8.9.3/Debian 8.9.3-21) id XAA04795; Thu, 9 Aug 2001 23:52:09 +0200 Original-To: Joe Casadonte In-Reply-To: (Joe Casadonte's message of "09 Aug 2001 15:56:39 -0400") User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105 Original-Lines: 135 Xref: main.gmane.org gmane.emacs.gnus.general:37656 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37656 Joe Casadonte writes: > On Thu, 09 Aug 2001, Kai Gro=DFjohann wrote: > >> Joe Casadonte writes: >>> 1) Despite everything I've tried, mostly with levels, I cannot >>> avoid having all accounts logged into at Gnus startup. I only >>> want two or three accounts checked, and I'll check the others >>> once every couple of days. Perhaps I need to define the virtual >>> servers but make them inactive somehow, and then manually >>> activate them from the server buffer? Aside from not knowing >>> how to do that off-hand, it seems a bit of a PITA. >> >> Hm. I've got a foreign nntp server that I'm not checking, and that >> works. Maybe Gnus is trying to look for new groups on the nnimap >> servers? You could try to make them foreign servers, rather than >> secondary. > > I can't seem to get this to work. How do I specify the .authinfo file > to use on a foreign server? I can do this with the secondary server > definition. Is there such a thing as Server Parameters (analogous to > Group Parameters)? I couldn't find anything in the info file. You can use one .authinfo file for many servers. Put the server name in the `machine foo' statement. Gnus ought to accept the server and the machine name there, but there have been a couple of changes in that area, so I'm not sure which versions do what. So if you have (nnimap "blarfl" (nnimap-address "frumple") ...) then it should work to have `machine blarfl' lines. >> A foreign server can be created via the server buffer, accessible >> via ^ from the Group buffer. Secondary servers are secondary >> because they're listed in gnus-secondary-select-methods. > > What is the real difference between a foreign & secondary server? > Just how you define it? And maybe the fact that foreign > servers/groups are not checked until explicitly asked? Gnus recognizes a secondary server by its presence in gnus-secondary-select-methods. The treatment of a secondary server differs from a foreign server in that Gnus checks for new groups on secondary servers, but not on foreign ones. >>> 2) Again, despite attempts to change the behavior (mostly with >>> levels) I cannot avoid having nnimap check every folder when I >>> do a gnus-group-get-new-news. The folders don't /activate/, >>> mind you, but I have to sit thru every one of them being >>> checked. >> >> Did you kill the unwanted groups (with C-k)? > > That removed it entirely :( Do you use topics? Maybe that group appears in two topics? This has happened to me before. Usually, I can make it go away by moving the group from one topic to the other with `T m'. If that fails, you might have to manually edit .newsrc.eld (the gnus-topic-topology line). But be careful! > I just want to have it not be activated until I ask for a certain > level to be activated. With nntp, I can have a group at a certain > level, say 3, and not have it be queried or even listed, until I asked > for it specifically. > > Example: I added an nntp group and set the level to 3. My > gnus-activate-level is set to 1. When I run gnus-group-get-new-news > this new group does not get queried. That's what I'd like to have > happen with my lower-level IMAP folders. It's what should happen automatically. If it doesn't happen, I think that's a bug in nnimap. Simon? >> Despite them thingies being listed in M-x list-processes RET, >> they're just network connections. No extra process needed for them. >> (Unless you connect to them via a shell command.) > > Bingo! I connect thru an SSH port forwarding tunnel. Nasty you, withholding information from us... ;-) >> Doing what you want would require a serious rewrite of the >> infrastructure. > > I would imagine so :( > >>> 4) As has been mentioned elsewhere in recent threads, nnimap (and >>> all of Gnus for that matter) is not terribly fault tolerant. If >>> a server connection goes down, the connection needs to be >>> severed manually before it can be reconnected. Again, this is >>> more of a general Gnus issue, I think, but nnimap seems a bit >>> more stubborn then nntp. >> >> Believe it or not, I never have those problems. When the connection >> goes down for some reason, Gnus brings it back up. Other than a >> slight delay, I don't notice anything. >> >> Do you use a shell command to access your IMAP servers (ssh, say)? >> That might be more problematic. > > Bingo again. So, not knowing enough about SSH, this is more an SSH > issue then a Gnus/nnimap issue? Hm. One idea might be to use ssh port forwarding. Maybe that helps. For example, I run ssh like this: ssh -f -L 10119:quimby.gnus.org:119 bonny -l grossjoh sleep 3600 This means that `telnet localhost 10119' gives me a connection to quimby.gnus.org which goes through bonny. Ie, the connection from localhost to bonny is encrypted via ssh, and the connection from bonny to quimby.gnus.org is in the clear, as required by nntp. This port forwarding is alive until the command (sleep 3600) terminates. Of course, the `sleep 3600' part has a high kludge factor. Not sure what to do about that. Also, you'd have to arrange for Gnus to start this on demand. There is also an -R option for ssh, which I've never understood. But I think that Gnus should provide a feature to check whether the connection to the remote end has gone down. The idea is like this: Gnus records the time when it sends a command to the remote host. And before sending a command, it looks how much time has elapsed since the last command. If that was more than, say, N seconds, Gnus sends a no-op command and looks carefully whether the remote end replies as it should. If the remote end doesn't reply, Gnus takes the connection down and tries again. kai --=20 ~/.signature: No such file or directory