From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9815 Path: main.gmane.org!not-for-mail From: Paul Franklin Newsgroups: gmane.emacs.gnus.general Subject: Re: new back-end interface to fix article move/delete problems Date: 04 Feb 1997 23:01:11 -0800 Sender: paul@cs.washington.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035149783 20726 80.91.224.250 (20 Oct 2002 21:36:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:36:23 +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 XAA14364 for ; Tue, 4 Feb 1997 23:10:43 -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 for ; Wed, 5 Feb 1997 08:01:18 +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 XAA00248; Tue, 4 Feb 1997 23:01:15 -0800 Original-Received: (from paul@localhost) by fester.cs.washington.edu (8.6.12/8.6.9) id XAA00715; Tue, 4 Feb 1997 23:01:14 -0800 Original-To: ding@ifi.uio.no In-Reply-To: Joe Wells's message of 23 Jan 1997 23:03:50 -0500 Original-Lines: 70 X-Mailer: Gnus v5.4.10/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:9815 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9815 [I've been meaning to respond for a while.] Joe proposed some backend interface modifications to fix problems with moving, etc. crossposted articles, which I'm assuming will make it into qgnus. I've attached an exerpt of the part relevant to me. In general, these seem great! However, I'm considering writing a backend based on nnml (if I can figure out the nnoo stuff) which might not be able to handle case 2a for an element of NEW-GROUP-ARTICLE. So I'm wondering when this case would get used. (If you're wondering, my imaginary backend allows mail delivery directly into group directories, so gnus might think the next article number in sequence isn't used when in reality it is. But I don't plan to eliminate the getting new mail step; this would scan the current mail spool, which now only contains enough information to update the overview and active files. I have no idea if I can get it to work; the crutial characteristic is that both the mail delivery agent and the gnus backend need to back off and keep incrementing their idea of the last message number if it exists, and the mail delivery agent also reads the backend's active file to avoid filling in holes.) --Paul >>>>> Joe Wells writes: > I have recently done a great deal of reimplementation to fix some problems > in using the mail-back-end commands to move, crosspost, and delete > articles that are crossposted inside the mail back end. This work > involves a new back-end interface *-request-modify-article which subsumes > the functionality of the *-request-move-article, *-request-accept-article, > and *-request-replace-article interfaces. > [...] > ---------------------------------------------------------------------- > SPECIFICATION OF *-request-modify-article INTERFACE > `(nnchoke-request-modify-article > SERVER OLD-GROUP-ARTICLE NEW-GROUP-ARTICLE BUFFER > &optional DONT-SAVE DONT-ADD-EXTRAS-TO-NEW)' > Replaces the article specified by SERVER and OLD-GROUP-ARTICLE with one > specified by NEW-GROUP-ARTICLE and BUFFER (and SERVER). This may involve > removing the article from some old groups and adding (crossposting) it to > some new groups. > [...] > 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). > NEW-GROUP-ARTICLE may be empty (causing only deletions of the article to > occur). NEW-GROUP-ARTICLE is automatically extended so as to include the > "extra" group/article pairs mentioned above. NEW-GROUP-ARTICLE may be > just t or contain the element t in addition to its ordinary alist pairs. > In this case, a list of groups will be added in place of the t based on > nnmail-split-methods and the contents of BUFFER. For each additional > group not already in NEW-GROUP-ARTICLE, a new pair (GROUP-NAME . ART-NUM) > or (GROUP-NAME . nil) is added, depending on whether such a pair is in > OLD-GROUP-ARTICLE. > [...]