Gnus development mailing list
 help / color / mirror / Atom feed
* nnimap: Server buffer vs secondary-select-methods
@ 2005-01-30 16:45 Mark Plaksin
  2005-02-04 19:50 ` David Abrahams
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Plaksin @ 2005-01-30 16:45 UTC (permalink / raw)


Checking nnimap groups added via the Server buffer is very slow unless you
also add them to gnus-secondary-select-methods.  When groups are added via
Server, Gnus opens a new IMAP connection each time it checks them.  I'm
using CVS Gnus updated today.

For example, I added a brand-new IMAP server via the Server buffer:
(nnimap "example"
        (nnimap-address "example.com")
        (nnimap-server-port 993)
        (nnimap-stream ssl)
        (nnimap-list-pattern
         ("INBOX" "Mail/*")))

Then I hit SPC on the new server and subscribed to a group.  After that,
whenever I g in the Summary buffer, Gnus will open a new connection to
example.com to check the folder.  It opens a connection every time I hit
g.

If I add the server to gnus-secondary-select-methods, Gnus opens the
connection once the first time it checks the folder and reuses the
connection after that.

Is there a reason for this behavior?  Surely I'm missing something!
Looking at the code, before the server is in gnus-secondary-select-methods
nnimap-server-opened decides the server isn't open because this
nnoo-server-opened call says it's not: 

  (nnoo-server-opened 'nnimap (or server nnimap-current-server))

I have always struggled to understand the difference between using the
Server buffer and using gnus-secondary-select-methods.  Today I made Gnus a
zillion times (no exaggeration :) faster by finally putting my IMAP servers
into gnus-secondary-select-methods.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nnimap: Server buffer vs secondary-select-methods
  2005-01-30 16:45 nnimap: Server buffer vs secondary-select-methods Mark Plaksin
@ 2005-02-04 19:50 ` David Abrahams
  2005-02-04 21:44   ` Mark Plaksin
  0 siblings, 1 reply; 3+ messages in thread
From: David Abrahams @ 2005-02-04 19:50 UTC (permalink / raw)


Mark Plaksin <happy@mcplaksin.org> writes:

> Checking nnimap groups added via the Server buffer is very slow unless you
> also add them to gnus-secondary-select-methods.  When groups are added via
> Server, Gnus opens a new IMAP connection each time it checks them.  I'm
> using CVS Gnus updated today.
>
> For example, I added a brand-new IMAP server via the Server buffer:
> (nnimap "example"
>         (nnimap-address "example.com")
>         (nnimap-server-port 993)
>         (nnimap-stream ssl)
>         (nnimap-list-pattern
>          ("INBOX" "Mail/*")))
>
> Then I hit SPC on the new server and subscribed to a group.  After that,
> whenever I g in the Summary buffer, Gnus will open a new connection to
> example.com to check the folder.  It opens a connection every time I hit
> g.
>
> If I add the server to gnus-secondary-select-methods, Gnus opens the
> connection once the first time it checks the folder and reuses the
> connection after that.
>
> Is there a reason for this behavior?  Surely I'm missing something!
> Looking at the code, before the server is in gnus-secondary-select-methods
> nnimap-server-opened decides the server isn't open because this
> nnoo-server-opened call says it's not: 
>
>   (nnoo-server-opened 'nnimap (or server nnimap-current-server))
>
> I have always struggled to understand the difference between using the
> Server buffer and using gnus-secondary-select-methods.  Today I made Gnus a
> zillion times (no exaggeration :) faster by finally putting my IMAP servers
> into gnus-secondary-select-methods.

Hmm, my imap server is my primary select method, and my Gnus could
stand to get a zillion times faster.  Do I have to make it a secondary
select method also?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: nnimap: Server buffer vs secondary-select-methods
  2005-02-04 19:50 ` David Abrahams
@ 2005-02-04 21:44   ` Mark Plaksin
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Plaksin @ 2005-02-04 21:44 UTC (permalink / raw)


David Abrahams <dave@boost-consulting.com> writes:

> Mark Plaksin <happy@mcplaksin.org> writes:
>

...

>> I have always struggled to understand the difference between using the
>> Server buffer and using gnus-secondary-select-methods.  Today I made Gnus a
>> zillion times (no exaggeration :) faster by finally putting my IMAP servers
>> into gnus-secondary-select-methods.
>
> Hmm, my imap server is my primary select method, and my Gnus could
> stand to get a zillion times faster.  Do I have to make it a secondary
> select method also?

I don't know about that.  After making my change, this is all that appears
in *Messages* when I check mail (assuming the IMAP servers are already open):

  Checking new news...
  Opening nnimap server on 1pof...done
  nnimap: Checking mailboxes...done
  Opening nnimap server on bor...done
  nnimap: Checking mailboxes...done
  Checking new news...done

Before I had a line (or three) for every single folder.

The key seems to have been getting (and keeping) the short name for my IMAP
server into what I see with G E in the Group buffer.  In the example G E
output below, it just has "bor" as the server name instead of
"nnimap+bor...".  I wasn't able to get that to stick until my IMAP servers
were secondary select methods.  I never tried making one of them the
primary select method.

G E output:
("nnimap+bor:Mail/bugzilla" 3
 "bor"
 ((uidvalidity . "1100103011")
  (timestamp 16899 59047)
  (total-expire . t)))





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-02-04 21:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-30 16:45 nnimap: Server buffer vs secondary-select-methods Mark Plaksin
2005-02-04 19:50 ` David Abrahams
2005-02-04 21:44   ` Mark Plaksin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).