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@gmail.com
wrote:
On 27.11.2010 00:04, Stephen Nuchia wrote:
From: Denis Shevchenko [mailto:for.dshevchenko@gmail.com]
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