Re: nnimap issues

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Simon Josefsson <simon@josefsson.org> writes:

> Then I wonder if it is the EXAMINE or the UID FETCH that is taken time,
> compared to the old approach of using STATUS.

On some servers the EXAMINE itself is slow, while on others it's fast.

> As I recall, this isn't specific to nnimap, and happens for all backends
> if there are holes in the article range.

Yes.  IMAP is unique, though, in that some servers have very sparse
article numbers, and that people read/delete messages from different
user agents routinely, and expect this to be reflected in all the user
agents... 

> But does it have to EXAMINE+FETCH all groups unconditionally?  I think
> it does that, right?  It could use the old approach with STATUS to
> quickly see what mailboxes have changed at all, and then for those
> (hopefully few) mailboxes that have changed, do the EXAMINE+FETCH dance.

But the problem is that STATUS will only say whether you've gotten a new
message, not whether you've read/deleted some of the messages via a
different user agent...

> Ah.  I think I got it: the old code sent the STATUS in parallel, like this:
>
> 1554 STATUS "INBOX.sent-2010" (UIDVALIDITY UIDNEXT UNSEEN)
> 1555 STATUS "INBOX.sent-2009" (UIDVALIDITY UIDNEXT UNSEEN)
> 1556 STATUS "INBOX.fossgrupp" (UIDVALIDITY UIDNEXT UNSEEN)
> 1557 STATUS "INBOX.apel-en" (UIDVALIDITY UIDNEXT UNSEEN)
>
> and then waits for all the replies.  The new code iterates through all
> groups and does EXAMINE+FETCH on each of them.
>
> What is biting now may be all the round trips.

No, they're still being streamed, like the old code.  nnimap now issues
a bunch of EXAMINE+FETCH commands, and then waits for the last response
to trickle in.  (Well, it usually doesn't wait, because this is now
issued early in the `g' cycle, so if you have other servers (like NNTP
or whatever), it'll issue the nnimap stuff first, then wait for the NNTP
stuff, and then look whether the IMAP stuff has arrived...)

However, it would make sense to allow the user to twiddle this.  If the
user only reads the IMAP groups from a single Gnus instance, then STATUS
would be fine.  Is that very common, though?

> 1) Parallel STATUS like the old code to discover which groups have been
> changed at all.
>
> 2) For those groups that have changed, do the EXAMINE+FETCH dance.

That would be possible, but then it'd have to wait for the STATUS
responses to arrive before doing any EXAMINE+FETCH stuff, which doubles
the round trips...

> That idiom brings back memories.  Glad to have you back working on Gnus,
> Lars!

It's fun to be back.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen