Re: new back-end interface to fix article move/delete problems

[Paul Franklin <paul@cs.washington.edu>]

[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.

 > [...]