Re: Returning to ticks on read-only imap servers

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

James Cloos <cloos@jhcloos.com> writes:

> LMI> So Gnus needs to now the status before doing anything, really,
> LMI> which seems to imply that nnimap has to do a SELECT on any
> LMI> mailboxes it hasn't seen before.  Hm.  That's actually not
> LMI> very difficult, since it already knows this stuff.
>
> A SELECT on any group it hasn't seen before is a good idea anyway.

Yeah.  I think I have a clear idea how to proceed here now.  For groups
it knows already, it'll output either EXAMINE+FETCH (or EXAMINE QRESYNC)
for the servers that support that.  For groups it doesn't know, it'll
output a SELECT+FETCH 1:*.  That SELECT will tell nnimap whether it
supports flags or not, and nnimap can then stash that info.

In the same sweep, it'll examine the EXAMINE results for mismatches in
UIDVALIDITY, and do an extra SELECT+FETCH 1:* for those groups.

So for normal `g' work, it'll be no slower than today (and much, much
faster for servers with QRESYNC).  Only the appearance of new groups, or
UIDVALIDITY mismatches, will trigger more chatter between Gnus and the
IMAP server.

I'll work on implementing this this weekend.  Once it's implemented, the
very first time you use Gnus after the push, Gnus will issue a
SELECT+FETCH 1:* for all your groups to get a complete data set again.

And I'll change where nnimap stashes the data.  I was confused, so I
stashed the active data (and stuff) in the info marks, while they should
be in the info parameters section.  This will also fix itself the first
time you run this.

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