Re: nnimap problem solved by removing .agentview and .overview

[Simon Josefsson <jas@extundo.com>]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

>> I'd even take another step back: Exactly what problem is in the design
>> of agent make it incompatible with nnimap?  I believe the designs are
>> pretty compatible.
>
> The agent assumes that the backend will never change the state of
> anything already known to the agent.  The fact that UIDVALIDITY exists
> is proof that that isn't the case with imap.

Right.  Even without the Agent, nnimap doesn't handle UIDVALIDITY
changes anyway, though...

> We could propagate the uid concept into the agent then have the agent
> verify its uid against the backend's uid before trusting its own
> cache.  It would probably work but I'm worried about the performance
> impact (would nnimap have to query the server each time the uid is
> checked?) and having to dummy up uid values for all of the other
> backends.

UIDVALIDITY is sent automatically when you enter a mailbox in IMAP, or
when you do a STATUS on a group (like Gnus does for each mailbox when
you press 'g'), so it doesn't cost much.  Nnimap store the current
uidvalidity as a group parameter too.  Nnimap.el used to compare the
value against the server, but there is no sane action nnimap.el can
take when the numbers doesn't match, so the comparison and user query
was disabled.

I share your feelings, it might hurt more than it pays to introduce
the uidvalidity concept in Gnus.  Perhaps still not that many IMAP
servers implement UIDVALIDITY in the right way too.  Some used to
increment UIDVALIDITY all the time (some used to set it to current
unix time...).  Some never increment it, even when UIDs are no longer
valid.  Ignoring UIDVALIDITY used to work better in practice, than
implement the proper handling of UIDVALIDITY changes.  That might have
changed, but then there is the problem of deciding how to actually
implement the proper handling, too..  it looks ugly.