Re: fast list

[James Cloos <cloos@jhcloos.com>]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Well, if you issue FETCH FLAGS, then you have to issue EXAMINE, too.

LMI> Returning the FLAGS for all the groups will be so much data that's it's
LMI> not generally useful. 

Why not?  It is what gnus does now, just one group at a time instead of
all in one go.

LMI> However, a global QRESYNC would be excellent.  QRESYNC works by
LMI> outputting all the flags that have changed since <SEQUENCE>.  So if
LMI> you said

LMI> LIST "" "%" RETURN (STATUS QRESYNC 43488328)

LMI> (or something) to return all the changed flags since that sequence
LMI> number, that would allow a really fast and comprehensive
LMI> server->client flag sync-up.

True, but adding QRESYNC requires adding CONDSTORE, and the latter is a
big project.  I'd expect several days to get it right.

LMI> Have a look at RFC5162 for the QRESYNC description, but there it's only
LMI> a parameter to EXAMINE/SELECT, so you still need to EXAMINE all the mail
LMI> boxes, annoyingly enough.

Yeah, we'd need to do an i-d to register another extended list option.

LMI> But here's a thought: nnimap could have a "sloppy" mode.  In the sloppy
LMI> mode, it doesn't care about syncing flags that comprehensively, and
LMI> instead deferring that to when you enter the group.  The sloppy mode
LMI> could work with the LIST RETURN command, for instance, or an EXAMINE run
LMI> (with no FETCH FLAGS).  It would just look at UNSEEN and UIDNEXT, and
LMI> just say "if UNSEEN is 5, and UIDNEXT is 242, then we say that all
LMI> messages between 1-236 are read, and the last five are unread".  When
LMI> the group is entered, it issues a "FETCH FLAGS" and gets things right.

LMI> But this could be result in pretty brittle behaviour if everything isn't
LMI> done just right...

That would be closer to the way other clients tend to work, I'd imagine.
If it did that for startup and g, then M-g could continue to work like now.

The equivilent of UID FETCH FLAGS for every group, if done as a single
command, takes about one or two seconds, vs 20 minutes iterating through
one group at a time.  I am eager to fix that.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6