Re: nnimap - not quite there yet?

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

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.

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.

Maybe you can create a server pointing to one of the existing accounts
and then you can see if you can prevent Gnus from checking that server
on startup.

> 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)?

Not sure whether the previous suggestion works for this one, too.

> 3) For each virtual IMAP server, an imap process is launched and kept
>    hanging around.  With 9 virtual servers, that's just too much.  It
>    would be much better if there was one IMAP process that kept
>    flipping back and forth.  Yeah, there's a lag with login and all,
>    but I'd rather have that then multiple connections hanging around
>    doing nothing.  One solution is to have a pool of IMAP connections,
>    the limit to which could be configurable (1 for me, N for others).

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.)

Doing what you want would require a serious rewrite of the
infrastructure.

> 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.

kai
-- 
~/.signature: No such file or directory