The infamous to-do list

[Russ Allbery]

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

> The actsync config files are horribly ugly and unclear and that whole
> mess should be reworked (which basically means rewriting actsyncd)
> instead. One of the things it has to support cleanly is syncing against
> multiple sources (e.g. my upstream for the standard groups,
> news.mozilla.org for netscape.*).

Good point.  Added.

> What is the procedure to get something into contrib? :-)

Mail it here or to me, or just make it available somewhere public and have
it draw my attention (and have an appropriate license).  :)

> Yes. The way I've already recommended this once goes as follows:
> 1. take the content of that line as string (built like now or perhaps
>    with additional info) into a buffer
> 2. if an encryption routine is built in and a key configured
>    then encrypt that buffer
> 3. output the buffer's content in base64.
> This way you generate a useful header whether encryption routines are
> available at install time or not.

The interactions with the O flag in newsfeeds need to be considered too,
plus it would be nice if X-Trace could be used by remote sites for rate
limiting (a la NNTP-Posting-Host) even in encoded form.  The same dialup
line encrypted and base64-encoded still provides a constant string to
filter against.

> Because it fits here: I have another wishlist item, standardized support
> for Cancel-Lock.

Yup, added.

>> * Revisit support for aliased groups and what nnrpd does with them.
>>   Should posts to the alias automatically be redirected to the real
>>   group?

> No. This breaks the least surprise principle and the don't touch the
> headers principle. Better reject the posting and leave it to the
> client to sort out (as good clients already do).

I clarified this point a bit.

> In the INN 1.x days someone wrote a C News-like configurable sendbatches
> driver; I'd like to see such a thing reappear. (Where you can configure
> the size, compression and sending method for each peer in a file and
> generate all batches with one command.)

Added.

> Speaking of SIGHUP, it would be nice if that could force a re-read of
> inn.conf. ;-) But I doubt that can be done, too much is static AFAICT.

Added.

> I'd like to see this "fix" limited to a narrow set of special cases like
> two-digit years, for the reasons stated above.

Noted.  I also added stricter checks for locally posted articles;
currently, INN will accept anything parsedate accepts, which includes a
lot of stuff that isn't even remotely RFC-compliant.

>> * nnrpd's NNTP command parsing interacts poorly with AUTHINFO and
>>   passwords containing spaces.  The correct solution isn't clear; check
>>   with the current NNTP RFC draft?

> Better (IMHO) first check with current clients' actual behavior. Not
> sure if this would break anything though.

Noted.

> I still favor the approach to drop the self-expire/non-self-expire
> distinction completely and treat the disappearing of articles as
> something which just does happen. This way you can use alternate expire
> programs, which may suit local policies or installation issues better,
> and the code gets less complex.

The problem is that this has other undesireable side effects.  LIST ACTIVE
and GROUP return different high/low marks, some clients see a bunch of
nonexistant articles, etc.

> Still further in the future would be a complete rework of the expire
> subsystem. I'd like a daemon which continually checks if articles are
> expired or to be expired and does the necessary work, instead of the
> current somewhat disruptive cron job. (To get this completely working
> would need all databases, including history, in a format which allows
> delete operations.)

This is definitely the direction that I'm heading.  The history file will
acquire such an interface with the next rewrite.

> One wishlist item for me (or is it implemented already in some way?):
> the filter should be able to tell innd to file the article into (an)
> additional group(s). This way I could define an extra group for local
> postings, or make a kibozing group, etc.

Not really implemented yet.  Added.

> The current reserve/pause/throttle scheme is completely broken. One of
> the more obvious problems is that expire fails if something else happens
> to pause the server at the wrong moment. A possible way around that
> would be a locking protocol that goes like this:

>   while (!reserve()) {
>     if (reason==throttled)
>       return ERROR;
>     sleep(30+random());
>   }
>   pause();
>   /* do work */
>   unpause();
>   unreserve();

> which is obeyed by _every_ program trying to access the history, active
> etc. Another thing is that the PID of the lock-holder should always be
> recorded in the lock message, to see if the process has died.

> This should all go into a library routine and probably into an "ctlinnd
> lock" command, of course.

Added.

Thanks!

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