Config file parser for lists
julien at trigofacile.com
Wed Apr 8 13:50:12 UTC 2009
Thanks a lot for your precious remarks!
>> It might also be a bit confusing as for the difference between the To: header,
>> the C<To> value and the C<To:full> overview field.
> Indeed, I don't know what you're talking about here.
In my mail, perhaps. But is it confusing when you read the suggested
documentation? I see that you did not make remarks on that so I assume
it was not confusing to read that nnrpd advertises "To:full".
>> If an unknown header name is listed, B<innd> will log an error
> Probably you should clarify here. A user without knowledge of INN's
> internals may not understand how a header name can be "unknown".
OK. I suggest:
The default value is an empty list (no additional fields are stored).
Owing to optimizations when B<innd> parses the articles it receives,
it is possible that all the values in the list are not recognized by
B<innd> as standard headers. In such cases, B<innd> will log an error
in F<news.err> at startup and the unrecognized fields will be discarded.
>> if you decide to add or remove a field from your overview database,
>> you should either modify I<extraoverviewadvertised> and rebuild
>> your overview database with makehistory(8) after removing all
>> existing overview files, or use I<extraoverviewhidden>.
> Consider: "implement a transition period by first using
> I<extraoverviewhidden> as described below."
That's far better. Thanks!
> Consider adding a cross-reference to expire.ctl here, as well as
> mentioning that time to expiration can be unpredictable with CNFS (and
> perhaps a mention of `cnfsstat -a` for checking on when buffers have
> rolled over).
If expire.ctl(5) is parametered so that all your articles expire within S<30 days>,
you can assume the database is in such a state after S<30 days>. However, note that
time to expiration can be unpredictable with CNFS and you then have to use
C<cnfsstat -a> for checking on when buffers have rolled over.
>> This parameter should be used in conjunction with
>> I<extraoverviewadvertised> (see it for more details).
OK. In fact, as it is the description of I<extraoverviewhidden>, I was not sure
whether it was wise to put "above" (in case inn.conf.pod is reorganized or the
names of the parameters changed, it might not still be accurate). But well,
"above" is prettier.
>> them in response to the LIST OVERVIEW.FMT command.
> That reminds me, at one or more points in this documentation, there
> should probably be something about how nnrpd handles HDR/XHDR for
> fields that are not in overview (and how that interacts with
All right. I suggest:
Overview data for these headers will be
generated for each new article at the time of arrival but, contrary
to the fields mentioned in I<extraoverviewadvertised>, B<nnrpd> will
not advertise them in response to the LIST OVERVIEW.FMT command. It
also implies that B<nnrpd> will not look in the overview database
for fields mentioned in I<extraoverviewhidden> when it handles HDR,
XHDR and XPAT requests; B<nnrpd> will have to parse the headers
of the requested articles in the news spool, which is slower than
directly querying the overview database.
« Ô temps suspends ton vol ! Et vous heures propices,
Suspendez votre cours. » (Alphonse de Lamartine)
More information about the inn-workers