From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50311 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: Why article numbers? Date: Sun, 23 Feb 2003 14:33:59 +0100 Organization: University of Duisburg, Germany Sender: owner-ding@hpc.uh.edu Message-ID: <84wujr86k8.fsf@lucy.is.informatik.uni-duisburg.de> References: <841y2jzrgm.fsf@lucy.is.informatik.uni-duisburg.de> <84el60hvg9.fsf@lucy.is.informatik.uni-duisburg.de> <84n0kn9vdh.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1046007336 2394 80.91.224.249 (23 Feb 2003 13:35:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 23 Feb 2003 13:35:36 +0000 (UTC) Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18mwI2-0000cK-00 for ; Sun, 23 Feb 2003 14:35:34 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18mwHl-0001Zp-00; Sun, 23 Feb 2003 07:35:17 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 23 Feb 2003 07:36:16 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id HAA02264 for ; Sun, 23 Feb 2003 07:36:03 -0600 (CST) Original-Received: (qmail 40205 invoked by alias); 23 Feb 2003 13:34:59 -0000 Original-Received: (qmail 40200 invoked from network); 23 Feb 2003 13:34:59 -0000 Original-Received: from quimby.gnus.org (80.91.224.244) by 66.230.238.6 with SMTP; 23 Feb 2003 13:34:59 -0000 Original-Received: from news by quimby.gnus.org with local (Exim 3.12 #1 (Debian)) id 18mwWH-00006Q-00 for ; Sun, 23 Feb 2003 14:50:17 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 58 Original-NNTP-Posting-Host: pd9e1e610.dip.t-dialin.net Original-X-Trace: quimby.gnus.org 1046008217 32238 217.225.230.16 (23 Feb 2003 13:50:17 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: 23 Feb 2003 13:50:17 GMT User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 Cancel-Lock: sha1:tk582ZUsNSDYOn6Th2aYiA7BoW8= Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50311 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50311 Simon Josefsson writes: > kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: > >> Simon Josefsson writes: >> >>> Regarding the nnimap issue, a better solution would IMHO be to fix it >>> to do proper re-syncing on UIDVALIDITY changes, which it probably >>> would have to do even if message-id's are used to index articles since >>> IMAP uses integers to retrieve articles anyway. >> >> Is this possible? > > To fix it? The situation is detected now (but ignored). What would > be required to make it work, would be to wipe out the gnus info for > that group and replace it with new data from the server. If the agent > is used, the NOV cache and .agentview and cached articles must be > removed too. As for cached articles, I'm not sure to handle them -- > removing locally cached articles might be a bad idea since the user > might want to keep them. Gnus-specific flags (i.e., bookmarks) simply > would have to be dropped unless some more information (like > message-id) about the marked articles were available to search for its > new article number. It is a lot of work, and no backend interface to > do it so nnimap would have to contain even more Gnus internal > knowledge. Fortunately, people rarely send bug reports about this (I > can rememeber <5 times this was the real cause of a problem) so either > it isn't that important or people give up Gnus for some other client > and doesn't tell us. Yeah. What I think should happen is a renumbering. For the cache, renumbering is actually easier, most of the time: just renumber the cached articles to start at 1, and you'll be fine in most cases. The copies in the agent are a thornier issue. I think it would not be good to just delete them: they will then be fetched again from the server, which is a waste of bandwidth that we wanted to avoid by using the agent in the first place... If you have an index of the local copies by message id, then you could just ask the server for the headers (NOV) and then search for articles mentioned there by message id. That tells you which number to use locally, and then there could be some articles that aren't found on the server -- we want to delete them I think. Hm. Maybe the cache should be treated a little bit like a separate backend, kind of like nnvirtual does it, at least conceptually. I think it would be best to just decouple the numbers used in the cache totally from the numbers used on the server. This leads to problems when the cached articles are still on the server, but oh, well. For the agent, the renumbering approach appears to be best. (`Lost' articles could be moved from the agent to the cache instead of deleting them, now that I think about it.) -- A preposition is not a good thing to end a sentence with.