From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9869 Path: main.gmane.org!not-for-mail From: Joe Wells Newsgroups: gmane.emacs.gnus.general Subject: Re: new back-end interface to fix article move/delete problems Date: 10 Feb 1997 23:32:26 -0500 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.103) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035149829 21056 80.91.224.250 (20 Oct 2002 21:37:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:37:09 +0000 (UTC) Return-Path: 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 UAA28300 for ; Mon, 10 Feb 1997 20:50:13 -0800 Original-Received: from cs.bu.edu (root@CS.BU.EDU [128.197.13.2]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 11 Feb 1997 05:32:36 +0100 Original-Received: from csb.bu.edu (jbw@CSB.BU.EDU [128.197.10.4]) by cs.bu.edu (8.8.5/8.8.5/(BU-S-01/27/97-fc1)) with ESMTP id XAA10805 for ; Mon, 10 Feb 1997 23:32:30 -0500 (EST) Original-Received: by csb.bu.edu (8.8.5/Spike-2.1) id XAA10509; Mon, 10 Feb 1997 23:32:26 -0500 (EST) Original-To: ding@ifi.uio.no In-Reply-To: Paul Franklin's message of 04 Feb 1997 23:01:11 -0800 Original-Lines: 52 X-Mailer: Red Gnus v0.81/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:9869 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9869 >>>>> "Paul" == Paul Franklin writes: Paul> Joe proposed some backend interface modifications to fix problems with Paul> moving, etc. crossposted articles, which I'm assuming will make it Paul> into qgnus. ... Paul> ... However, I'm considering writing a Paul> backend based on nnml (if I can figure out the nnoo stuff) which might Paul> not be able to handle case 2a for an element of NEW-GROUP-ARTICLE. So Paul> I'm wondering when this case would get used. The relevant part of the proposed back-end-interface: >> NEW-GROUP-ARTICLE is an alist whose members are of the form (GROUP-NAME >> . ARTICLE-NUMBER) or (GROUP-NAME . nil). The group names must be distinct >> from each other and must not include any server prefix. If any of the >> named groups do not exist, they will be created. For each (GROUP-NAME >> . XXX) pair in NEW-GROUP-ARTICLE, one of the following must be true: >> 1. (GROUP-NAME . XXX) is a member of OLD-GROUP-ARTICLE. >> 2. GROUP-NAME does not appear in OLD-GROUP-ARTICLE and either: >> a. XXX is an article number not already used in group GROUP-NAME. >> b. XXX is nil (indicating an unused article number in group >> GROUP-NAME should be allocated). There are two goals behind possibility 2a (neither of which have been implemented): 1. An article is originally crossposted in groups A, B, and C as articles 5, 6, and 7 (respectively). The user removes it from group C. Later, the user asks for the the article to be crossposted in group C. It should be possible to reuse the old number 7 rather than the number that would be given to a new article. 2. The user asks for an article to be crossposted to group A. The article was originally sent in 1994 (three years ago). If the article is given the number in group A that would be given to a new article, then it may be listed in the summary buffer for that group after many articles that are actually newer than it. If there were gaps in the sequence of existing article numbers in group A, it should be possible to use one of the numbers in the gaps instead, so that the article gets listed in a more natural order. Goal number 2 is more questionable than goal number 1. 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. -- Joe Wells