Re: nnimap - not quite there yet?

[Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)]

Joe Casadonte <jcasadonte@northbound-train.com> writes:

> On Thu, 09 Aug 2001, Kai Großjohann wrote:
>
>> Joe Casadonte <jcasadonte@northbound-train.com> 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
-- 
~/.signature: No such file or directory