From: Forrest J. Cavalier III (mibsoft@epix.net)
Date: Tue Nov 06 2001 - 15:25:44 CST
Brad Templeton <brad@templetons.com> wrote:
> To wit, for the server, implementation is quite simple
>
> There are two easy methods:
>
> 1) If when you cancel, you are able to rewrite the history entry of
> the cancelled article, then simply do so to provide some pointer to the
> replacement, or to an index into a smaller side-database (gdbm is fine)
> of replacements.
>
> 2) If you can't alter old records, just add a new replacement record to
> the database. When you fetch an article by message-id, and you notice
> it is gone, check for the replacement record. You only do this when
> you can't find an article, so it's not expensive.
>
You outlined a partial solution in two paragraphs. How can leaving
out all the interesting pieces be adequate to make your point?
Look, if you haven't implemented a key based data locator, it is
easy to gloss over important and complicated issues such
as consistency, locking, expiration, and clean up tools, especially
when you must support concurrent access, deletions, duplicates,
and replacements. Supporting duplicate keys is a pain too.
When there are performance isses and caching, the implementation is
that much more interesting.
Looking at a dbz+history file implementation to say it will work is
not acceptable. INN's dbz implementation is creaking and groaning
under present loads. I predict it will have to be replaced within
several years.
Your two paragraphs did not address the Xref header generation
either.