The infamous to-do list

[Russ Allbery]

Olaf Titz <olaf at bigred.inka.de> writes:

> This can be done by formatting the (rest of) the header in a way that
> fields are always a multiple of 8 bytes and applying a 64 bit block
> cipher in ECB mode on it. But then we would be better off using binary
> fields, as the timestamp is 9 bytes and an IP address 10-12 bytes.

Added more about this to TODO.  Thanks!

> GROUP should use the marks from the active file. Of course one can argue
> the real problem is that nnrpdcheckart is too slow. We have this problem
> with CNFS too. A cleanup deamon which continually monitors the existence
> of articles and purges old entries from overview would help.

Particularly if you could tell it that you just blew away a timecaf buffer
or a timehash directory so that it could go do cleanup right away.

> The expire job should be split into three separate processes for the
> three separate jobs it does: expiring articles, history entries and
> overview, and in my imagined ideal world these three should be truly
> independent from another.

In my ideal world, INN would be able to handle minor inconsistencies but
the normal state of the server would be to have all three in sync at
pretty much all times.  It really bugs me that right now, CNFS expires
articles throughout the day but the overview only gets updated at night.
But that's just one more case where the whole idea of a nightly expire
just isn't what you want.

> Good. :-) Hopefully we can finally do away with dbz and the text file
> (which today really is only a bloated-by-hex-conversion binary file
> anyway). I expect to test a Berkeley DB based history as soon as I
> can...

I'll be glad to see that tested, but I'll be really surprised if it beats
a hand-tuned database format in performance.  There are a couple of minor
tweaks that I plan to make to the current history format to create a new
default one, and of course the current text file will become binary by
default (part of the plan is to be able to read any older history format
too, though), but I think the layout of the index and so forth is actually
fundamentally sound.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>