Hi Jose, Thank you very much for your review.
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)
The scope of the library is beyond program configuration. It can also be used to manipulate DOM-like structures (which are trees), pass data inside program etc. ProgramConfiguration would be misleading, it would suggest the library is a superset of Program Options, which it isn't.
2. Relation to other libraries I think the relation to the Boost.ProgramOptions library is not clear. Maybe it should !
I will add into the docs (in prominent place) the goals/problem domain statement I posted several days ago. I will also expand it with PO/serialization/multi-index relationships.
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.
Correct. Serialization cannot be used for saving ptree file formats. In general it is not meant to save arbitrary configuration files, even with provision of custom archives. The format it follows it quite rigid, and cannot easily be changed.
* 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
tree.hh is GNU GPL licensed. Cannot use it in boost. Also, because it is a generic tree container, its interfaces are inevitably generic as well. It has very different strucuture from ptree, for example it does not have keys, so you cannot use paths. It does not provide any type-conversion mechanisms. It would require a large facade to be used in a role of property tree.
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.
The basic_ptree class is "the framework". I cannot think about any other thing that different formats might have in common, so that it can be factored out into some utility. For a very simple format, writing a parser in spirit to populate ptree is not much more that 1 screen of code, most of which is boilerplate anyway.
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.
The problem is that this may never happen. Also, when it happens it might turn out that the resulting library (being powerful and standards-compliant), will be cumbersome to use in simple cases. Best regards, Marcin