From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58246 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap problem solved by removing .agentview and .overview Date: Fri, 13 Aug 2004 00:28:40 +0200 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 1092366570 27142 80.91.224.253 (13 Aug 2004 03:09:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Aug 2004 03:09:30 +0000 (UTC) Original-X-From: ding-owner+M6788@lists.math.uh.edu Fri Aug 13 05:09:24 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 1BvSRY-0006rs-00 for ; Fri, 13 Aug 2004 05:09:24 +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 1BvSR1-0000Y0-00; Thu, 12 Aug 2004 22:08:51 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BvSQn-0000Xg-00 for ding@lists.math.uh.edu; Thu, 12 Aug 2004 22:08:37 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BvSQl-0001rs-0S for ding@lists.math.uh.edu; Thu, 12 Aug 2004 22:08:35 -0500 Original-Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by justine.libertine.org (Postfix) with ESMTP id 7E7D53A00B3 for ; Thu, 12 Aug 2004 22:08:34 -0500 (CDT) Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BvSFL-0002Jj-00 for ; Fri, 13 Aug 2004 04:56:47 +0200 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Aug 2004 04:56:46 +0200 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Aug 2004 04:56:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 37 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:P6iB0a5YJphj6j2pNMw58+R8oKs= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:58246 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58246 Kevin Greiner 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.