INN config file parsing infrastructure

Forrest J. Cavalier III mibsoft at epix.net
Thu May 4 16:20:52 UTC 2000


> 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.

With a programmatic interface to the config files, it should
be the task of the library to preserve comments.  And then it is
the responsibility of programmers to use that interface to make 
changes, and not just rewrite files.  

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.  Even if comments,
    formatting and whitespace are preserved as Fabien requires
    (difficult) it is significantly harder to preserve order,
    and particular string encodings.

           These two strings are equivalent.
           These\x20two\x20strings\x20are\x20equivalent.

    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....

-----------------------------------------------------------

Hope that was clear, (at least to Russ.)




More information about the inn-workers mailing list