Re: Returning to ticks on read-only imap servers

[Julien Danjou <julien@danjou.info>]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Fri, Oct 08 2010, Lars Magne Ingebrigtsen wrote:

> 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.

That overlaps was I was saying in an earlier mail today, using
UIDVALIDITY to resync everything rather than fetch the 100 last mails.

The only question left is, are you forced to to a FETCH 1:*, isn't a
STATUS enough? That would be very faster. You'd do the FETCH on group
entering.

My 2¢,

-- 
Julien Danjou
// ᐰ <julien@danjou.info>   http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]