From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9901
Path: main.gmane.org!not-for-mail
From: Paul Franklin <paul@cs.washington.edu>
Newsgroups: gmane.emacs.gnus.general
Subject: Re: new back-end interface to fix article move/delete problems
Date: 12 Feb 1997 00:56:20 -0800
Sender: paul@cs.washington.edu
Message-ID: <r9q914ujtcb.fsf@fester.cs.washington.edu>
References: <xnjvi8nk9cp.fsf@csb.bu.edu> <r9qlo93u47c.fsf@fester.cs.washington.edu> <xnjraioezdx.fsf@csb.bu.edu>
NNTP-Posting-Host: coloc-standby.netfonds.no
X-Trace: main.gmane.org 1035149857 21211 80.91.224.250 (20 Oct 2002 21:37:37 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Sun, 20 Oct 2002 21:37:37 +0000 (UTC)
Return-Path: <ding-request@ifi.uio.no>
Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2])
	by deanna.miranova.com (8.8.5/8.8.5) with SMTP id BAA31236
	for <steve@miranova.com>; Wed, 12 Feb 1997 01:15:40 -0800
Original-Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) 
	id <JAA22740@ifi.uio.no> for <ding@ifi.uio.no> ; Wed, 12 Feb 1997 09:56:24 +0100
Original-Received: from fester.cs.washington.edu (fester.cs.washington.edu [128.95.4.119]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with ESMTP id AAA17127; Wed, 12 Feb 1997 00:56:21 -0800
Original-Received: (from paul@localhost) by fester.cs.washington.edu (8.6.12/8.6.9) id AAA04692; Wed, 12 Feb 1997 00:56:20 -0800
Original-To: ding@ifi.uio.no
In-Reply-To: Joe Wells's message of 10 Feb 1997 23:32:26 -0500
Original-Lines: 18
X-Mailer: Gnus v5.4.10/Emacs 19.34
Xref: main.gmane.org gmane.emacs.gnus.general:9901
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9901

>>>>> Joe Wells writes:

 > A reasonable restriction of the proposed back-end-interface would be to
 > require that a non-existing article number must be one that the article
 > used earlier that has since been deleted.  This would support goal 1 but
 > not goal 2.  It would also probably avoid the problems that Paul
 > envisioned.

Yup.  I would also be perfectly happy with the lesser restriction that
it be less than the highest known article number (specified in the
active file), since I'm only worried about articles which might exist
above that highest known article number.

I just didn't want someone to decide to supply 1 more than the last
number in the active file because "I know what article number the
backend would use."

--Paul