From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37436 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Backend writing Date: Sat, 04 Aug 2001 01:35:14 +0200 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035172852 13858 80.91.224.250 (21 Oct 2002 04:00:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:00:52 +0000 (UTC) Cc: ding@gnus.org Return-Path: Return-Path: Original-Received: (qmail 29798 invoked from network); 3 Aug 2001 23:33:55 -0000 Original-Received: from dolk.extundo.com (195.42.214.242) by gnus.org with SMTP; 3 Aug 2001 23:33:55 -0000 Original-Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f73NY4w00586; Sat, 4 Aug 2001 01:34:04 +0200 Original-To: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) In-Reply-To: (Kai.Grossjohann@CS.Uni-Dortmund.DE's message of "Sat, 04 Aug 2001 00:07:41 +0200") Mail-Copies-To: nobody User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.104 Original-Lines: 45 Xref: main.gmane.org gmane.emacs.gnus.general:37436 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37436 Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: >> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes: >> >>>| that number, or Gnus will get mightily confused.@footnote{??? Is >>>| this still true with the nnchoke-request-*-mark* functions?} >>>| Third, article >> >> It's still true. > > But haven't you just changed nnimap to ignore article renumberings? I > suppose you wouldn't do that unless it's safe? I don't know if it's safe, that's what Oort is for. Basicly, nnimap makes sure the old NOV cache isn't used when a uidvalidity has changed. Nnimap also updates all Gnus marks when entering a group so they should be OK. The only thing left is the active range, and that's updated by Gnus when you `g', `M-g' or somesuch. Possibly a uidvalidity change breaks the cache or the agent if article numbers are actually re-used. But in several cases IMAP servers update UIDVALIDITY but still does not re-use article numbers, so in those cases it's OK to ignore the error. It gets sort of ugly if a backend has to update internal things of Gnus's cache and agent. Some sort of mechanism to handle renumberings in the cache and agent would be nice. >>>| The previous paragraph already mentions all the `hard' >>>| restrictions that article numbers must fulfill. But it seems that >>>| it might be useful to assign @emph{consecutive} article numbers, >>>| for Gnus gets quite confused if there are holes in the article >>>| numbering sequence. However, due to the `no-reuse' restriction, >>>| holes cannot be avoided altogether. >> >> I would say "is slowed down" instead of "gets quite confused". I >> don't think there are any problems, other than that the >> `gnus-range-*' functions start to take very long time. Some IMAP >> servers leave large holes. > > I meant that Gnus says `1276423 messages in this group, how many?' or > something like that when the user enters the group. That's another side-effect of the high/low article number story. It's documented, so maybe we could call it a feature. For now at least.