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

[Joe Wells <jbw@cs.bu.edu>]

>>>>> "Paul" == Paul Franklin <paul@cs.washington.edu> 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 <jbw@cs.bu.edu>