readers.conf proposal: (was Re: incoming.conf length limits)

[Todd Olson]

At 17:59 -0500 2003/01/27, Jeffrey M. Vinocur wrote:
>On Mon, 27 Jan 2003, Todd Olson wrote:
>
>> PROPOSED for readers.conf:
>>
> >    access_additions {
> > [ ...]
>
> > QUESTION:
>> how much work would it take to add such a block to readers.conf??
>
>In 2.4, it would be doable but require some pounding on the parser which
>would be a bit of a waste since the whole parser is going to get ripped
>out and replaced with Russ's generic config parser.  However, adding that
>at the time the parser is replaced might be doable.

makes sense to wait then ...

>
>
>> PS ... hum I guess there would be details, like if access_additions
>>        had a 'nnrpdauthsender: true' would that turn is on globally,
>>        or only for the added groups. 
>
>I think we'd prohibit everything except users:, key:, read:, and post: --
>can you think of any good reasons to support other parameters?

No.
I was just thinking along the lines of a copy/paste duplication of current
access code and then realized that there could be complications.

>
>
>Actually, wait.  Maybe we don't need to add another block type at all. 
>What about just changing the semantics of access blocks by making
>append-all-matching-access-blocks a standard thing, modified either by a
>"break: true/false" keyword or a "fallthru: true/false" keyword (depending
>on what seems most intuitive to people, and backwards-compatibility
>issues) to allow the admin to stop the appending process as desired.
>
>Thoughts on that instead?
>

This approach would work for me as well.

The fallthru: (or continue:) with a default of 'false' seems the most
backwards compatible (TMWOT).

Regards,
Todd Olson
Cornell University