Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Hal Finkel (half_at_[hidden])
Date: 2010-11-27 21:24:31

On Fri, 2010-11-26 at 18:48 -0600, Jeff Benshetler wrote:
> I've switched to using Python for configuration files about 6 years ago, and
> stopped writing "little languages" of my own. There is a great deal of
> flexibility and extensibility from using a general purpose language, and it
> has a fully documented syntax with good error messages.
> 

I think some care is required here. Bringing in an embedded scripting
language to a project is not necessarily straightforward, easy or
desirable, even if using Boost.Python, luabind, etc.

While I think the advantages of using an embedded scripting language are
clear, there can also be disadvantages:

1. Scripting languages, even simple ones like Lua, are large, external
codebases, generally written in C. These codes can have porting issues,
packaging/distribution/installation issues, thread-safety issues, etc.
In addition, non-trivial build-process modifications might be necessary.

2. Execution safety might be hard to guarantee when using an embedded
scripting language, especially for those that allow the loading of
external modules. It might be reasonable to read a configuration file
from an untrusted source while not being reasonable to execute a script
from an untrusted source. In addition, using the scripting language
could be significantly slower than using a dedicated configuration-file
parser. A script could enter an infinite loop, as an extreme example. In
short, there could be security implications. 

3. Many scripting languages have their own I/O facilities, which may or
may not be customizable or able to interface with iostreams classes, and
are often tied to low-level operating-system I/O primitives.

4. A scripting language might not match user expectations. Especially on
POSIX-style systems, users (and even more so, administrators) have a
general understanding of the "look and feel" of a configuration file.
The syntax used by the Apache httpd web sever, for example, is very
popular, is easy to transform in an ad-hoc way using standard
command-line tools and is straightforward to understand. Denis's
Configurator library seems to use the same general style.

5. Error checking when using the scripting language may be harder,
especially if the script configures the application by invoking
application-side object creation. Since the scripting language can "do
anything," there are lots of possible invalid uses to guard against.
Also, since there are many different possible ways to use the scripting
language for configuration, there will be no real uniformity across
applications, even those which use the same embedded language.

Finally, scripting languages and configuration-file languages are
designed with different priorities: scripting languages are often
designed to make writing programs easy while configuration-file syntax
is designed to be simple both to read and to write. There is, of course,
a large spectrum on the scripting language side: one might reasonably
argue that it is easier to make hard-to-read programs in Perl than in
Lua or Python, but it is hard to make a hard-to-read Apache httpd
configuration file; That can be important.

I think a library for configuration-file parsing would be quite useful.
There are may use cases where an embedded scripting language is best,
but I think there are also many for which a dedicated
configuration-file-parsing library is superior.

 -Hal

> On Fri, Nov 26, 2010 at 5:31 PM, Denis Shevchenko <for.dshevchenko_at_[hidden]
> > wrote:
> 
> > On 27.11.2010 00:04, Stephen Nuchia wrote:
> >
> >> From: Denis Shevchenko [mailto:for.dshevchenko_at_[hidden]]
> >>>> Is there any interest in a library for configuration file parsing?
> >>>>
> >>> Having done this once, just before TCL was announced, I won't ever do it
> >> again.  Ousterhout's reasoning is, in my opinion, unassailable.
> >> Configuration files might as well be written in a full-featured,
> >> widely-understood embedded scripting language.
> >>
> >> http://www.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf
> >>
> >> That would be Python now, right?
> >>
> >>
> >> _______________________________________________
> >> Unsubscribe&  other changes:
> >> http://lists.boost.org/mailman/listinfo.cgi/boost
> >>
> > Hmm... Sorry, but I do not quite understand your idea... TCL, Python... I'm
> > not familiar with script languages.
> >
> > I propose a C++-solution which seems to me a easy-to-use and flexible and
> > which I use myself for all my Linux-daemons. And I suggested that if this
> > solutionseems convenientto me, It may seem convenient for others developers.
> > I'm just trying to determine the interest in it...
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost