Config file parser for lists

Julien ÉLIE julien at trigofacile.com
Tue Apr 7 10:59:09 UTC 2009


Hi Jeffrey,

> What about doing:
>
> extraoverviewadvertised:  [ ]
> extraoverviewsilent:      [ ]    (or extraoverviewhidden?)

That's a great idea.  Adopted!


> which would take the onus off the user in terms of deciphering that one is
> a subset of the other, order matters, etc, since you would just include
> the advertised ones first and the silent ones later.

Order would still matter on removal or on adding previously hidden fields.

I suggest the following documentation for inn.conf.  Feel free to reword
it if it seems obscure and Frenglish.  Please also tell me if you see
additional things to mention.
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.




=item I<extraoverviewadvertised>

Besides the seven standard overview fields (which are in order C<Subject:>,
C<From:>, C<Date:>, C<Message-ID:>, C<References:>, C<:bytes> and
C<:lines>) and the eighth C<Xref:full> field required by INN in order
to handle crossposts, it is possible to add other fields in the
overview database.  This parameter expects a list of such header
names.  Overview data for these additional headers will be generated
for every incoming article.  For instance, if you specify:

    extraoverviewadvertised: [ Path NNTP-Hosting-Host ]

it implies that B<nnrpd> will advertise C<Path:full> and
C<NNTP-Hosting-Host:full> as the ninth and tenth fields in response
to LIST OVERVIEW.FMT and that these two headers will be stored in the
overview database for every new incoming article.

The default value is an empty list (no additional fields are stored).
If an unknown header name is listed, B<innd> will log an error in
F<news.err> at startup and the relevant field will be discarded.

You should advertise only fields for which the overview database
is consistent, that is to say it records the content or absence
of these fields for I<all> articles from the beginning.  Consequently,
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>.

If for instance you want to store the To: header in addition
to the fields already stored above, you should use:

    extraoverviewadvertised: [ Path NNTP-Hosting-Host ]
    extraoverviewhidden:     [ To ]

This way, C<To:full> will not be advertised by B<nnrpd> but will
be stored for every new incoming article.  Once you know that
all articles in your overview database record the content or absence
of that new field (if all your articles expire within S<30 days>,
you can assume the database is in such a state after S<30 days>),
you should use:

    extraoverviewadvertised: [ Path NNTP-Hosting-Host To ]
    extraoverviewhidden:     [ ]

The C<To> value must be added at the end of the list because
order matters and fields mentioned in I<extraoverviewhidden>
are generated after those mentioned in I<extraoverviewadvertised>.
B<nnrpd> will now advertise C<To:full> in response to the LIST
OVERVIEW.FMT command (C<full> indicates that the header appears
followed by its value).

Now suppose you want to remove the NNTP-Hosting-Host: header.
As order matters, the overview database will no longer be consistent
for the To: header.  Therefore, you need to specify:

    extraoverviewadvertised: [ Path ]
    extraoverviewhidden:     [ To ]

And once overview data is accurate for all articles, you should use:

    extraoverviewadvertised: [ Path To ]
    extraoverviewhidden:     [ ]

Note that you have to restart B<nnrpd> if it runs as a daemon
whenever you change the value of I<extraoverviewadvertised>; a mere
C<ctlinnd xexec innd> is not enough.

=item I<extraoverviewhidden>

This parameter should be used in conjunction with
I<extraoverviewadvertised> (see it for more details).  It expects
a list of headers names.  Overview data for these headers will be
generated for every incoming article but, contrary to the fields
mentioned in I<extraoverviewadvertised>, B<nnrpd> will not advertise
them in response to the LIST OVERVIEW.FMT command.

The default value is an empty list (no additional fields are stored).
If an unknown header name is listed, B<innd> will log an error in
F<news.err> at startup and the relevant field will be discarded.




That's all.

-- 
Julien ÉLIE

« Rien n'est plus agaçant que de ne pas se rappeler ce dont on ne parvient
  pas à se souvenir et rien n'est plus énervant que de se souvenir de ce qu'on
  voudrait parvenir à oublier. » (Pierre Dac) 




More information about the inn-workers mailing list