From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58243 Path: main.gmane.org!not-for-mail From: Kevin Greiner Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap problem solved by removing .agentview and .overview Date: Thu, 12 Aug 2004 16:30:38 -0500 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <871xidtl04.fsf@mail.contactor.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1092346330 18944 80.91.224.253 (12 Aug 2004 21:32:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 12 Aug 2004 21:32:10 +0000 (UTC) Original-X-From: ding-owner+M6784@lists.math.uh.edu Thu Aug 12 23:32:02 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BvNB3-00081G-00 for ; Thu, 12 Aug 2004 23:32:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BvN9y-0007Zo-00; Thu, 12 Aug 2004 16:30:54 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BvN9q-0007Zi-00 for ding@lists.math.uh.edu; Thu, 12 Aug 2004 16:30:46 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BvN9n-0007FW-QK for ding@lists.math.uh.edu; Thu, 12 Aug 2004 16:30:43 -0500 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id DCE743A0242 for ; Thu, 12 Aug 2004 16:30:42 -0500 (CDT) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1BvN9l-0006ds-00 for ; Thu, 12 Aug 2004 23:30:41 +0200 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 99 Original-NNTP-Posting-Host: dialup-216-12-206-11.ev1.net Original-X-Trace: quimby.gnus.org 1092346241 25535 216.12.206.11 (12 Aug 2004 21:30:41 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Thu, 12 Aug 2004 21:30:41 +0000 (UTC) User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (windows-nt) Cancel-Lock: sha1:jnoOna9lGhuARJRr+N91AkoRkC0= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:58243 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58243 Simon Josefsson writes: > "Steven E. Harris" writes: > >> Kevin Greiner 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? Some requests are only intercepted with running unplugged. For example the request to get the active range is passed through to the backend with running plugged. Let's work an example for those reading along. Yesterday, we'll asume that your active range consisted of eight messages (numbered 1 through 8) and that you used gnus to view the folder's summary so all eight are known to the agent. Today, we'll assume that two new messages have arrived so we know that your active range is now 1-10. When gnus starts it queries the server for the current active range so now gnus knows that your active range is 1-10. Now, you open the folder to display the summary buffer. The summary functions make a request for all article headers in the range 1-10. That request is redirected to the agent by gnus internals. The agent checks its .overview file, sees that it has headers for articles 1-8 (from yesterday) and forwards a modified request for the range 9-10 to the server. The agent gets the headers for articles 9-10 from the server, merges them into its .overview so that it never needs to ask the server for them, then constructs a response that satisfies the summary buffer's original request for article headers in the range 1-10. >> 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. 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. 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. >> 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... I agree. Kevin