From: Russ Allbery (rra@stanford.edu)
Date: Thu Mar 02 2000 - 19:45:55 CST
Brad Templeton <brad@templetons.com> writes:
> On Thu, Mar 02, 2000 at 03:15:34PM -0800, Russ Allbery wrote:
>> 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.
The history database has around 10M entries on the average reader server
carrying a full feed. Assuming 4-byte integers, you've just added ~40MB
to the size of the history file to implement a fairly obscure feature. I
definitely wouldn't take this approach; an extra external database is much
more efficient given that the vast majority of articles won't have
versions.
> If your database doesn't let you do that, then you might use another
> database such as gdbm for just the versioned messages.
Well, I'd never use gdbm for anything ever, but yes, something like that
would be what I'd do.
> It's not a lot of code.
It's also not a very compelling feature, IMO.
Anyway, I agree that it's implementable in INN given INN's Xref semantics
(if really ugly, IMO), and that the history database isn't necessarily the
sticking point (although it's also definitely not something you can just
drop in to existing history databases).
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>