From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Tue Mar 07 2000 - 05:11:02 CST
In <ylu2ijcsrh.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:
>Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>> If dbz is basically a device for mapping Message-IDs into an offset
>> within the history file,
>It's not. The whole concept of an offset into a text file is going away.
>A lot of it is gone already, even in the current development sources, and
>the rest of it will go away for at least one history backend if I ever
>manage to find the time to get to the history rewrite.
OK, if you have now managed to make the History file use fixed-length
binary fields, then "offset into a text file" becomes simply "address
within binary file". Comes to the same thing.
>So in the long run, in-place updates should be possible with at least some
>of the history backends, but duplicates likely won't.
Sure, if in-place updates are possible, the whole problem goes away. The
solution proposed before was intended for current systems where updating
history in situ was just not on (but we still need that solution as a fall
back, because many servers still operate that way).
>Mapping article numbers to storage API tokens is done via overview.
>Mapping message IDs to storage API tokens is done via history.
Fine! Do we actually need Xref header in articles anymore if the
information is in the voerview?
Anyway, the missing mapping is the one from API to article numbers. That
is the one we need do the Replaces properly. It can be done by going to
the article and extracting the Xref, but there may be simpler ways.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5