Re: Faster nnimap: nnimap-retrieve-groups-asynchronous

["Bjørn Mork" <bmork@dod.no>]

Simon Josefsson <jas@extundo.com> writes:

> I tried to speed up new mail checking (`g') on IMAP groups.  Startup
> uses old technique, but subsequent `g' can be faster.  The speedup
> depends on how many groups usually receives new mail each time you
> press `g' (the p below).  It might depend on the server as well.  For
> me, it is faster against Cyrus IMAPD -- results from other servers
> would be interesting.

This speeded up mail checking noticably on all my imap servers, but
unfortunately it's causing a problem with one of them. I could of
course turn it off, but then I lose the performance gain... So I'm
hoping the problem can be fixed.

I currently use three imap servers:
a) IMAP4 server (InterMail vM.4.01.03.23 201-229-121-123-20010418)
b) Courier-IMAP ready. Copyright 1998-2001 Double Precision, Inc.
c) Courier-IMAP ready. Copyright 1998-2002 Double Precision, Inc.

I can't do server side splitting on a) and b), so I'm using a
nnimap-split-rule on them. c) is doing server side splitting using
procmail. 

The problem is that Gnus doesn't detect new mail split into a folder
on b) when pressing 'g'. Doing a 'M-g' on the folder will however show
the new mail. The funny thing is that everything works fine on server
a) and c). So it looks like a combination of a Courier server and
client side splitting is causing the problem, unless there is a
specific problem with the Courier version running on b).

This is a small extract of the imap-log on server b):

91 EXAMINE "INBOX"
* FLAGS (\Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ()] No permanent flags permitted
* 131 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 979914089] Ok
91 OK [READ-ONLY] Ok
[..]
95 EXAMINE "INBOX.Trash"
* FLAGS (\Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ()] No permanent flags permitted
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 979914089] Ok
95 OK [READ-ONLY] Ok
[..]
128 STATUS "INBOX.Trash" (uidnext)
* STATUS "INBOX.Trash" (UIDNEXT 1)
128 OK STATUS Completed.
[..]
170 UID FETCH 370 BODY.PEEK[HEADER]
* 131 FETCH (UID 370 BODY[HEADER] {1628}
[snip mail]
170 OK FETCH completed.
171 UID COPY 370 "INBOX.Trash"
171 OK COPY completed.
172 UID STORE 370 +FLAGS (\Seen \Deleted)
* 131 FETCH (FLAGS (\Seen \Deleted))
172 OK STORE completed.
173 EXPUNGE
* 131 EXPUNGE
* 130 EXISTS
* 0 RECENT
173 OK EXPUNGE completed
174 CLOSE
174 OK mailbox closed.
175 STATUS "INBOX.Trash" (uidnext)
* STATUS "INBOX.Trash" (UIDNEXT 1)
175 OK STATUS Completed.


Hmm, definitely looks like a server problem when I'm looking at it
now. Shouldn't the UIDNEXT value change between command 128 and 175? 
Is this a known problem with the Courier server?

Maybe I should do some experiments with client side splitting on my c) 
server, too.


Bjørn
-- 
So, your ten-incher is great?