Re: RFC 1036 Revision: Replaces/Supersedes/Xref Headers

New Message Reply About this list Date view Thread view Subject view Author view

From: Brad Templeton (brad@templetons.com)
Date: Fri Mar 03 2000 - 14:19:19 CST


On Fri, Mar 03, 2000 at 07:47:09PM +0000, Andrew Gierth wrote:
> >>>>> "Brad" == Brad Templeton <brad@templetons.com> writes:
>
> >> And this is the other part I have a problem with - in a cluster
> >> system the Xref is generated in the hub, and so this step fails if
> >> the article being replaced has expired from the hub's spool (which
> >> is small compared to that of the reader systems).
>
> Brad> Does that mean it leaves the hub's history file too?
>
> No, but the history file doesn't have article numbers in.

So what about adding 'em? That does solve all the issues, at a cost of
disk space in the history file. Disk space is hardly expensive.
>
> Brad> Anyway, I guess it means that the tools that actually generate
> Brad> the article number have to generate the xref. Is this not
> Brad> possible in your design?
>
> The hub assigns the article numbers (how else is it going to generate
> the Xref?)
>
> The basic setup for an xref-slaved cluster is like this. You have a
> hub system, which has a spool only as big as it needs (retention maybe
> measured in hours at best), and no overviews. This takes incoming
> articles from transit servers, allocates numbers to them using its
> active file, generates Xref headers using those numbers, and feeds out
> the articles to some number of reader boxes (which have big spools,
> and overviews, but which use the article numbers from the Xref headers
> rather than generating their own).

But they must do other things, like interpret cancel messages, no? How
do they do cancel messages if they don't have a history file mapping msgids
to numbers? They can use this to either replace-in-place or add something
to the xref line.

This disturbs the "purity" of the xref line but it is a local header, and is
not meant to be pure.

One would start with an xref containing the current intended article number,
but the local node could decide to add the old number to that line, or
store the article under the old number.


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.