Re: [boost] [Boost Review] Property Tree Library

[mailto:boost-bounces@lists.boost.org]On Behalf Of Thorsten Ottosen I have the great pleasure to announce that the formal boost-review of Marcin Kalicinski Property Tree Library begins now (the 18th * What is your evaluation of the design? * What is your evaluation of the implementation? I think that both the design and the implementation are sound, clearly a great deal of thought and effort went into this design. I like the container-like interface so that I can iterate through the tree but more so I like the ability to just enter the full path to the element that I want with out first having to search for it.
* What is your evaluation of the documentation?
I think it could use some expanding upon. First, as was already mentioned, the index needs to be broken up into smaller topics. Next I think there should be more discussion (tutorial) on customizing the library.
* What is your evaluation of the potential usefulness of the library?
Great! My opinion is that this library is going to see far more usage than just what it was intended for. My initial reaction when I looked at it is that it's more of a generic hierarchical tree, moreover, once you've populated your tree you can save it off and come back to it another day. Just taking those two aspects into consideration opens the door to a lot of possibilities, far more than just reading configuration data.
* Did you try to use the library? With what compiler? Did you have any problems?
In process
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
So far only a few hours, but more to follow.
* Are you knowledgeable about the problem domain?
To a degree, yes.
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
Absolutely! I think this library will be suitable for a number of applications.
In particular, consider if you can answer the following questions:
- was the library suitable for your daily xml-tasks? If not, what was missing?
- was the library's performance good enough? If not, can you suggest improvements?
Performance is a concern given the recursive nature of the tree. I want write a test case parsing Usenet's group list. By it's nature it demands storage in a hierarchical tree where every node is both a leaf and a branch (like ptree :) , it's a big list, and insertion / retrieval is mostly random. Hopefully I'll have time to do this before the review is over.
- was the library's design flexible enough? If not, how would you suggest it should be redesigned to broaden its scope of use?
The number one place I see this library being specialized, both by the users and the maintainer, is in the parsers. Case in point, my above test requires me to write a different parser. I think it would be useful in the long run to have a basic_parser<...> that could be inherited from as an interface to the user who needs to write their own parser. All the preprocessor stuff, or other implementation details, can be hidden there so that the user just inherits and parses away. There may be other places where customization hooks make sense... Any thoughts? regards, Matt Doyle
best regards
Thorsten Ottosen, Review Manager
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Scanned by McAfee GroupShield {X3BTB534}

Matt, Thanks for your review so far. Matt Doyle wrote:
In particular, consider if you can answer the following questions:
- was the library suitable for your daily xml-tasks? If not, what was missing?
- was the library's performance good enough? If not, can you suggest improvements?
Performance is a concern given the recursive nature of the tree. I want write a test case parsing Usenet's group list. By it's nature it demands storage in a hierarchical tree where every node is both a leaf and a branch (like ptree :) , it's a big list, and insertion / retrieval is mostly random. Hopefully I'll have time to do this before the review is over.
- was the library's design flexible enough? If not, how would you suggest it should be redesigned to broaden its scope of use?
The number one place I see this library being specialized, both by the users and the maintainer, is in the parsers. Case in point, my above test requires me to write a different parser. I think it would be useful in the long run to have a basic_parser<...> that could be inherited from as an interface to the user who needs to write their own parser. All the preprocessor stuff, or other implementation details, can be hidden there so that the user just inherits and parses away. There may be other places where customization hooks make sense... Any thoughts?
Let me just say (as a review maanger) that such a test would be immensely useful (an an obvious candidate for inclusion with the library if it is accepted). I know it is an easy task, though. -Thorsten

I think it could use some expanding upon. First, as was already mentioned, the index needs to be broken up into smaller topics. Next I think there should be more discussion (tutorial) on customizing the library.
I agree there is little docs on customizing the library. The reason is I underestimated interest people will take in that part of the library. Also, customization support was added quite late in the development. I probably thought too much along the lines of my own use of the library - I never needed to use the customization features.
* What is your evaluation of the potential usefulness of the library?
Great! My opinion is that this library is going to see far more usage than just what it was intended for. My initial reaction when I looked at it is that it's more of a generic hierarchical tree, moreover, once you've populated your tree you can save it off and come back to it another day. Just taking those two aspects into consideration opens the door to a lot of possibilities, far more than just reading configuration data.
In some of my past projects I used it as a primitive serialization library, where data files are human editable (and creatable). This is hard to achieve using boost::serialization, even with XML archive, because boost::serialization serializes lots of housekeeping information, which is in not easy to grok by human (like class-id integers or tracking ids). Another use of ptree was in a program where user interface was communicating with the "working" part of the program by means of property trees. This allowed running the "working" part alone (without the interface) - it was transparently reading ptrees from the disk instead of getting them from interface. Thank you, Marcin

"Marcin Kalicinski" <kalita@poczta.onet.pl> wrote in message news:e26a9b$3b1$1@sea.gmane.org...
...
In some of my past projects I used it as a primitive serialization library, where data files are human editable (and creatable).
In past projects, I have found human editable (and creatable) configuration/serialization files to be *very* useful. I'm glad to hear that your library supports such files. --Beman

In past projects, I have found human editable (and creatable) configuration/serialization files to be *very* useful. I'm glad to hear that your library supports such files.
Oh yeah it does. That was the very thing that brought it into existence ;-) Marcin
participants (4)
-
Beman Dawes
-
Marcin Kalicinski
-
Matt Doyle
-
Thorsten Ottosen