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

[Simon Josefsson <jas@extundo.com>]

"Steven E. Harris" <seh@panix.com> writes:

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

Gnus is supposed the invoke these SEARCH requests every time, upon
entering the group, to sync all flags, and its list of which articles
exists.  However, if you only press 'g' and then ask the agent to
fetch articles, the group might not have been entered, so nnimap
haven't had any chance of updating the information.

However, if entering and exiting a group when plugged in doesn't
notice all articles, there is a bug.  I suspect the problem lies in
the agent rather than in nnimap, or (perhaps even more likely) in
interaction between nnimap and the agent.

Is there a simple recipe for reproducing this?

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

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.

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

Not many people are working on nnimap.el, nor improving the generic
backend interface, these days, it seems...