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

["Steven E. Harris" <seh@panix.com>]

Kevin Greiner <kgreiner@xpediantsolutions.com> writes:

> The problem is that, when the agent is turned on, your backend
> requests don't go directly to the backend.  They instead go to the
> agent which tries to respond using what it has locally cached.  If,
> and only if, you request something that is not in the cache, will the
> agent request the MISSING content from the real backend.

How is one ever able to see something that something exists that is
not locally cached? How does Gnus ever know that there is something
new on the IMAP server that it has not seen?

Also, I thought this behind-the-back-change is what the IMAP
UIDVALIDITY response is supposed to help discern. I thought that with
UIDVALIDITY Gnus could detect that it wasn't the last client to have
altered the mailbox. Reading RFC 3501, I see that's not the case;
change in UIDVALIDITY only warns that the old message IDs may have
changed.

What if, upon contacting the IMAP server and noting agreeable
UIDVALIDITY, Gnus does a SEARCH or UID query from its last known
message ID, checking to see if any new IDs are present that would not
have appeared in a check for what is UNSEEN? Isn't there some way like
this to figure out that the server has messages that the client has
never heard of?

> Frankly, I don't see how to make the agent work better with nnimap
> without introducing nnimap specific code into the agent or changing
> the backend interface.  Neither is something to take lightly so I
> don't believe that this situation will be changing anytime soon.

Are these interfaces documented somewhere? It's hard to comment on
potential solutions without knowing the current constraints. Again,
it's surprising that even after four or five years of Gnus supporting
IMAP, we still haven't done better than other IMAP clients.

-- 
Steven E. Harris