DRAFT: [ANNOUNCE] INN 2.3.0 available
Forrest J. Cavalier III
mibsoft at epix.net
Wed Jul 12 13:00:49 UTC 2000
> INN 2.3.0 represents a significant architectural change to INN, with a
> completely new internal overview interface, three new overview mechanisms,
> two new article storage mechanisms, and the elimination of quite a few old
> interfaces and old code.
Might want to mention the need to convert history and overview to
the new formats. (Just a pointer to the appropriate section in the
> * Unified overview has been replaced with an overview API, and there are
> now three separate overview implementations to choose from. One
> (tradindexed) is very like traditional overview but uses an additional
> index file for faster responses to readers. The second (buffindexed)
> uses circular buffers and can handle a higher incoming article rate
> while still being fast for readers. The third (ovdb) uses Berkeley DB
> to store overview information (so you need to have Berkeley DB
> installed to use it). The ovmethod key in inn.conf chooses the
> overview method to use.
buffindexed is not a circular buffer. It is block-oriented, but if
you run out of space, INN throttles. expire does the equivalent of
a realloc(), not a circular overwrite. (Katsuhiro please correct me
if I'm wrong.)
I wouldn't bill tradindexed as faster than INN 1.x .overview. It
requires more open descriptors, extra reads and writes. There
is the problem that if you use overchan to write tradindexed, and overchan
doesn't keep up, articles are inaccessible. (.overview in INN 1.x
is just an accelerator, and INN succeeds even if .overview
is missing. The 1.x traditional spool did not need .IDX files, since
that function was done by the file system and the assignment of the
article number as the file name.)
> * To simplify anti-abuse filtering, and to be more compliant with news
> standards and proposed standards, INN now treats as control messages
> only articles containing a Control header. A Subject line beginning
> with `cmesg ' is no longer sufficient for a message to be considered a
> control message, and the Also-Control header is no longer supported.
I'm too pressed for time right now to look at the code. Was
that 'cmsg' or 'cmesg'?
> * The INN build system no longer uses subst. This should be mostly
> transparent to users, apart from the old annoyance of modifications to
> include files being overridden again by subst when building INN being
> a thing of the past.
The wording confuses me. "a change is transparent, except" cues up
a caveat, not a benefit. I'd drop everything but the first sentence.
I'm curious why there still is a subst(1) manpage in INN 2.3.
Is subst used anywhere?
More information about the inn-workers