The documentation may be viewed online at
BTW, this URL has timed-out every time I've tried the past week. But the docs were in the zip file in the boost vault.
* What is your evaluation of the design?
Seems good. I like that I can write get("myvalue",default) which will always return, or get("myvalue") which will throw if not found. The use of <xmlattr> to access attributes is ugly, but I don't have a better suggestion (except shortening it slightly to "<attr>"). One alternative would be a get_attr() family of functions but that they would be XML-specific, so that is uglier.
* What is your evaluation of the implementation?
Didn't look.
* What is your evaluation of the documentation?
Good enough. It needs a few minor fixes by a native English speaker. I didn't see the need for get_own(), so that could do with a motivating example.
* What is your evaluation of the potential usefulness of the library?
I think it fits the desired goal of reading in a configuration file. Versus Program Options: I've not used this library, but when I skimmed the library docs yesterday I didn't see examples of reading an XML configuration file. Or JSON. Versus Serialization: Hhhmmm... Firstly I've seen people saying the serialization library is a heavyweight solution. In terms of number of lines you need to write I've not found this. It is as simple to use as Property Tree. If I was reading/writing a config file and the editing of settings was only done through my program, then I would definitely use the serialization library. The problem with the serialization library is that the XML format is not easy to edit. I doubt it can be friendlier and still work, or Robert Ramey would have done it that way? There is a need to be able for a program to be able to write to its setting file but also have the settings file be easy to view and edit. The Property Tree library fills this need.
* Did you try to use the library? With what compiler?
No.
* How much effort did you put into your evaluation?
Just reading the docs once, and following the discussion here.
* Are you knowledgeable about the problem domain?
Not particularly.
* Do you think the library should be accepted as a Boost library?
Ideally I think it should be merged into the Boost Serialization library as additional format options (i.e. in addition to the current binary, text and xml formats, add easy-to-read-xml, json and ini files). If, as I suspect, that is technical not feasible, then I vote Yes.
- was the library suitable for your daily xml-tasks? If not, what was missing?
Probably not. XML files containing lots of data (as opposed to a relatively short, human-editable configuration file) usually use namespaces, entities, CDATA, etc. I usually use PHP for dealing with such files, and I'm satisfied with that. Darren