From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/50305 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Why article numbers? Date: Sun, 23 Feb 2003 12:04:56 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: 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 1045998417 5700 80.91.224.249 (23 Feb 2003 11:06:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 23 Feb 2003 11:06:57 +0000 (UTC) Cc: ding@gnus.org 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 18mtyC-0001To-00 for ; Sun, 23 Feb 2003 12:06:56 +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 18mtwd-0000b8-00; Sun, 23 Feb 2003 05:05:19 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 23 Feb 2003 05:06:18 -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 FAA01990 for ; Sun, 23 Feb 2003 05:06:04 -0600 (CST) Original-Received: (qmail 34467 invoked by alias); 23 Feb 2003 11:05:00 -0000 Original-Received: (qmail 34452 invoked from network); 23 Feb 2003 11:05:00 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by 66.230.238.6 with SMTP; 23 Feb 2003 11:05:00 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.7/8.12.7) with ESMTP id h1NB4uXf005206 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 23 Feb 2003 12:04:57 +0100 Original-To: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Mail-Copies-To: nobody X-Payment: hashcash 1.1 0:030223:kai.grossjohann@uni-duisburg.de:c44a73e4c40c9eac X-Hashcash: 0:030223:kai.grossjohann@uni-duisburg.de:c44a73e4c40c9eac X-Payment: hashcash 1.1 0:030223:ding@gnus.org:80a915ede7c0b277 X-Hashcash: 0:030223:ding@gnus.org:80a915ede7c0b277 In-Reply-To: <84n0kn9vdh.fsf@lucy.is.informatik.uni-duisburg.de> (kai.grossjohann@uni-duisburg.de's message of "Sun, 23 Feb 2003 10:52:42 +0100") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:50305 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:50305 kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes: > Simon Josefsson writes: > >> How would you handle two messages with the same message-id? Or no >> message-id (think drafts)? Since it is possible to create that >> scenario, Gnus should IMHO handle it. I think an abstract data type >> separated from the message itself is more flexible. I see two >> problems with the use of integers today: handling sets of integers can >> be slow, and the integer limit in emacs is too small. > > Do you think dealing with a set of 1,000,000 integers is slower than > dealing with a set of 1,000,000 strings, say? I don't know, but I suspect not. > For the integer limit, well, err, somebody should do bignums in Emacs > Lisp :-) Yes, please. :-) >> 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.