[boost] Property Tree library review

From: Jose (jmalv04_at_[hidden])
Date: 2006-04-27 12:53:18

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.