Re: [boost] Property Tree library review

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-28 08:38:35

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