From: Brad Templeton (brad@templetons.com)
Date: Thu Mar 02 2000 - 19:35:36 CST
On Thu, Mar 02, 2000 at 03:15:34PM -0800, Russ Allbery wrote:
> Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>
> > The intended implementation is that you leave the old one in the history
> > file (Expires will eventually remove it) and add a new one at the
> > end. You then ensure that dbz always gives you the latest one. I looked
> > at the dbz in CNEWS, and that seemed easily implementable, so I suppose
> > the same would go for INN. We discussed this at length some months
> > ago. Is there any real problem there?
>
> It's certainly not simple. In INN, like most current news servers, the
> keys to the history database are not message IDs; they're hashed forms of
> message IDs. The actual message ID isn't stored anywhere in history in
> current INN. So you'd need to use an extra external database to do the
> version number mappings for Replaces.
Depends on your goal. In the history file, you just need a way to find
out the current version of a given message-id. There are a lot of
ways to do this. Let's assume that we require version numbers to be
integers. I had not intended to require this, but if so, it's easy to
create a "Current-version-number-for-xxxx" record which returns the
integer, and you change that integer with each new version. It is a fixed
field, so you can rewrite it in place on the disk if you wanted to.
If your database doesn't let you do that, then you might use another database
such as gdbm for just the versioned messages. It's not a lot of code.
While we might not want to require versions to be integers, I think it's
entirely reasonable to say they are strings limited to some number of bytes,
like 16, so that you can allocate a constant amount of space that can
be efficiently rewritten.