Property Tree library review
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.
Jose wrote:
* 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
Also for setting configuration data and simlpe xml-files? Mind you, many people would like a generic tree in boost, but few has said property_tree should be one too. And the interface of that tree is rather large (which of course is handy whn you need that). The fact that keys are duplicated in a map to provide fast lookup kinda rules out it to be a generic tree container where overhead is not acceptable.
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.
Not only should it be explained in the docs, but it should be decided if this is what the library is intended to do. And if yes, how would that framework look like? -Thorsten
On 4/27/06, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Jose wrote:
Also for setting configuration data and simlpe xml-files?
tree.hh is only the container. but if you look in source forge there are some libraries that use it to read DOMs and serialize them
The fact that keys are duplicated in a map to provide fast lookup kinda rules out it to be a generic tree container where overhead is not acceptable.
but with a generic container you don't need to duplicate the keys, you just walk the tree. My main issue with PT is how to query the tree (see PT xml parser thread) It's a design issue but I look for Boost libraries that provide general solutions that can also be used in a specific/specialized context.
This also should be explained in the docs.
Not only should it be explained in the docs, but it should be decided if this is what the library is intended to do. And if yes, how would that framework look like?
I don't mean my specific examples per se . If the focus is on a specific container then the parsers are more important as you're likely to encounter examples that are hard to handle If the parsers are utilities then fine but if someone wants to write their own parser then the container is limiting (e.g. in W3 DOM the node can not just be an string key)
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
On 4/28/06, Marcin Kalicinski <kalita@poczta.onet.pl> wrote:
Hi Jose, 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.
For that wider scope I think the library is completely unappropiate because: 1) It doesn't use a generic container, which limits its use to very simple DOM structures 2) It doesn't follow any of the standards: W3 DOM and XPath 3) It devalues what is currently expected from Boost libraries Also, the simplicity argument is not good for DOM-like structures b/c it's a broad problem domain. I truly believe the PT fits the category of "Utilities" more than a Boost library. My vote then was meant to be a strong NO.
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.
I mentioned tree.hh as an example of what should be provided but a better example is the Tree Container Library , http://www.codeproject.com/library/tree_container.asp The author plans to submit it to boost, so maybe we should wait for that I believe Boost has to aim for state-of-the-art libraries not utilities. 1) There is nothing bad about generic interfaces. They allow you to handle a wider set of DOM structures. 2) The argument it doesn't have keys is wrong, because you have a node object (and you can have a key). And the way PT handles paths is bad (at least for my requirements and as pointed out in a separate thread) Sorry to be so negative about the proposed library. I am not a Boost expert but I have used tree.hh and other libraries in this problem domain. I liked your simplicity argument for the program configuration domain but trying to broaden the scope as a library for DOM-like structures cleary makes the library inappropiate as pointed out in the arguments above Regards
I just wanted to add I agree with Jose's comments: the library looks useful for loading/saving configuration files, but I don't think it should try to be "boost::tree". So ProgramConfiguration name suggestion seems appropriate. Darren Jose wrote:
On 4/28/06, Marcin Kalicinski <kalita@poczta.onet.pl> wrote:
Hi Jose, 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.
For that wider scope I think the library is completely unappropiate because:
1) It doesn't use a generic container, which limits its use to very simple DOM structures 2) It doesn't follow any of the standards: W3 DOM and XPath 3) It devalues what is currently expected from Boost libraries
Also, the simplicity argument is not good for DOM-like structures b/c it's a broad problem domain. I truly believe the PT fits the category of "Utilities" more than a Boost library. My vote then was meant to be a strong NO.
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.
I mentioned tree.hh as an example of what should be provided but a better example is the Tree Container Library , http://www.codeproject.com/library/tree_container.asp The author plans to submit it to boost, so maybe we should wait for that I believe Boost has to aim for state-of-the-art libraries not utilities.
1) There is nothing bad about generic interfaces. They allow you to handle a wider set of DOM structures.
2) The argument it doesn't have keys is wrong, because you have a node object (and you can have a key). And the way PT handles paths is bad (at least for my requirements and as pointed out in a separate thread)
Sorry to be so negative about the proposed library. I am not a Boost expert but I have used tree.hh and other libraries in this problem domain. I liked your simplicity argument for the program configuration domain but trying to broaden the scope as a library for DOM-like structures cleary makes the library inappropiate as pointed out in the arguments above
Regards _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Darren Cook -
Jose -
Marcin Kalicinski -
Thorsten Ottosen