I vote a weak NO. I would change this to yes once the library has some decent functionality to select values by path (see the related thread on testing the PT xml parser) I also have some general comments about the name, scope and design of the library: 1. The library name I think the library should be named after what it does (not how it does it). The property tree is the container but in this case the library is about program configuration - Boost.ProgramConfiguration (there are other libraries where a more technical name is better because of the library scope, like the property map library, but not for this one) 2. Relation to other libraries I think the relation to the Boost.ProgramOptions library is not clear. Maybe it should ! Without having used the PO lib, I think the PT lib is a superset, focusing on both command-line and file-based configuration. The use of the Spirit library for the xml parser is good. Using other boost libraries like serialization, .. do not seem correct for this specific library. 3. The scope This is the strong point of this library. I has the potential to be widely useful as it can be used in any program to load and save the program settings 4. The design * The strong points: I think the only strong point is the focus on simplicity. I think this attracts everybody attention as the library can be quickly used and everybody sees and specific use right away but I see many design issues too - see below * The weak points: a) The container The use of a generic tree container has not been seriously considered. The argument against using a generic container is that it would complicate the library. I don't agree. For a specific example check the tree.hh library: an STL-like C++ tree class http://www.aei.mpg.de/~peekas/tree/ This library provides a generic tree container and well thought-out interfaces. It is as easy or easier to use than the PT lib b) The parsers (library vs utilities) It is not clear whether the parsers are utilities or whether the PT lib is supposed to provide some framework to build specific parsers. E.g. * How easy is to use this existing file format with ":" separator name1: value1 name2: value2 * How easy is to use a more advanced format, e.g. a CSS file h1 { font-family: arial; font-size: 12px; } .show { ... } This also should be explained in the docs. d) Relation to standards The library has been presented many times as a sort of DOM ...
From the docs: "One can think of it as a sort of Document Object Model, which is minimalistic, ..."
I think this is a fallacy, because there are standards like the W3 DOM and XPath that are widely useful and widely used, and taking these out of the design just limits what the library can do (if the standards were both not widely useful and widely used then I would think otherwise). Again, the argument is simplicity but I think with a generic tree container, like tree.hh, these standards can be supported without complicating the usage. Conclusion ---------------- Maybe one way out of this conundrum is to consider the current library as the basic one and later have an advanced version that really provides the generic container and the proper query mechanisms.