bug#56332: 29.0.50; Large gnus imap groups; articles incorrectly marked as read (old)

[Lars Ingebrigtsen]

Michael Welsh Duggan <mwd@md5i.com> writes:

> 2) When the problem happens, it seems to happen because the order of the
>    fetch responses do not appear in the order of the fetches themselves.

Oh, that's interesting.  IMAP is a streaming protocol, so if you send
two commands after one another, you should first get the responses from
the first, and then from the last.  It sounds like UID FETCH doesn't
respect that?

In which case the simple solution would be to wait until the first
command has ended before issuing a new one, but that would make things a
bit slower (depending on the latency of the connection).

Hm...  OK, I've tried this myself now, and I can definitely see
something odd here.  I don't see shuffled headers, but I see

OUTPUT FROM FIRST
OUTPUT FROM SECOND
26166 OK Fetch completed (0.002 + 0.000 + 0.001 secs).
26167 OK Fetch completed (0.002 + 0.000 + 0.001 secs).

So that seems to support this -- UID FETCH is not really streamable (at
least not with this IMAP server).  I'm using Dovecot -- are you using
the same?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no