INN config file parsing infrastructure

Fabien Tassin fta at
Thu May 4 16:21:06 UTC 2000

According to Forrest J. Cavalier III:
> > IHMO, such a lib should be able to do some manipulations on a file such as :
> > - check/read/write a whole file (and perhaps its dependancies)
> > - add/remove/desactivate/activate a section or a group
> > - launch optionnal actions for each event (previously quoted) using hooks.
> > 
> > With that, we will be able to make another lib (eg libctlinn) with a well
> > defined API that can be used by external tools like ctlinnd, CGI apps,
> > PINN manager and the like to dynamicaly configure INN on a per feed/reader
> > basis.
> > 
> Programmatic interface is something that I'm sure Russ has in
> the back of his mind.
> You can't remove comments from the syntax. Comments are a
> necessary feature in any hand-edited file, and config files
> are going to be hand-edited for a long time.

I don't want to remove comments but I think it is mandatory to have
comments that can be in the semantic of the grammar so they can be
remembered and changed by non-humans.

> With a programmatic interface to the config files, it should
> be the task of the library to preserve comments.

it is really hard to do if it is not covered by the grammar.

>  And then it is
> the responsibility of programmers to use that interface to make 
> changes, and not just rewrite files.  

Sure but both INN and the interfaces can check the date of conf files
and decide to automaticaly reload them (like Diablo) or ask the user
what to do (like Emacs) or just warn to syslog (like Sendmail).

> Which brings up a related issue, which may be the one Fabien was
> thinking of as well....
> In order for there to be a programmatic interface to make
> changes, each configuration item has to be uniquely "addressable."
> Loading into a structure and writing out again is not going to
> work well. 
> Consider:
>   - It requires that the configuration tool have an up to date
>     compile against the structure.  This like the fragile base class
>     problem of C++.  Let's avoid it if possible.
>   - It will lose string encodings and ordering.

encoding, perhaps but with an appropriate structure, there's no ordering

>   Even if comments,
>     formatting and whitespace are preserved as Fabien requires
>     (difficult)

hmm.. I've never asked such thing because I know it's not easy to do.
it requires both orderings and non-semantic tokens to be added to
the parser with no rule in the grammar (except that these tokens are allowed

> it is significantly harder to preserve order,
>     and particular string encodings.
>            These two strings are equivalent.
>            These\x20two\x20strings\x20are\x20equivalent.

no. Just keep the real string in memory and use a "decode" method when needed.
(or keep both strings in memory).
>     Trumped up example, but may be significant to some users.
>     Ordering certainly is significant.
> So, Russ, I'd just ask that you be thinking of including something
> in any API to just read/write one particular configuration
> file item.  (And that means thinking about adressing schemes.)
> Full parse and loading into a structure is great for most uses,
> but does suffer when it comes to writing isolated changes or in the
> case there is the "fragile base class problem."  Most of what
> INN uses from config files is localized, but there are occasionally
> cases where some program just wants to know one little detail
> from some other config file....

In fact, I don't think that my proposals are unrealistic or too hard to
implement because I already made a similar thing in a big network management
system I've created. Unfortunatly, a) this part is in Perl and b) I can't
release the sources.

Fabien Tassin -+- fta at

More information about the inn-workers mailing list