Design issues for nntp storage manager

Alex Kiernan alexk at
Tue May 15 09:58:00 UTC 2001

I've had someone looking at this, using a head feed from an article
server to a reader server for overview information then nntp to
retrieve the full article, but we've run into some issues.

The header only feed bit is straightforward, but figuring out what the
nntp storage manager token should look like is causing problems.

My original thought was to build a database (probably Berkeley DB
based) of nntp sm token to msg id; whilst this is straightforward, its
another database to manage.

An alternate thought was to make the sm token a group number and
article number, but this then requires a static group number (which we
don't have today) and retrieving articles from the feeding server will
only work by message id (assuming its not running an overview), so a
mapping through overview would be needed.

Both have the issue of storing which article server a message is
stored on (but thats probably easy to throw into the token somehow
like cnfs does).

A hook to rewrite the history for whole articles we received when they
got overwritten in a cnfs can would be needed (but not during expire,
I think).

Anyone any thoughts?

Alex Kiernan, Principal Engineer, Development, Thus PLC

More information about the inn-workers mailing list