This is my second review of the library (I mistakenly reviewed rev4 before). Since Marcin plans to change the get/set interface of the library it would be better to arrange review for rev6, within reasonable time interval (few months, not in a year). I would be happy with current acceptance as well, as futher improvement are very likely. The library has potential to be very useful for real world application (in current form and even more in rev6). Clearly, domain for the library is to read/write configuration data, not to serve as generic tree or complete XML parser. Temptation to extend the now simple API into giant does-it-all tool may result in something practically no one would dare to use. I do not see the overlap with PO as obstacle. Merge between PT and PO is unlikely - I have never seen anything like this on Boost so far. Things that need improvement: ------------------------------------------ 1. Examples, examples, examples. Adding many small but complete examples into documentation is the most effective way how to increase acceptance of the library among users. No one is interested in reading lenghty manual just to get a value from INI. If the documentation is already too big drop reference, heck, drop anything but add examples. As others had pointed, there is more to improve in the documentation. 2. Limitation of the library should be clearly spelled, especially for XML. I am in favour to limit XML features as much as possible - it is not task of simple configuration tool to provide validating parser and whatnot. Rename te library to "simple property tree" if people cannot stop requesting more. Existence of ptree is no barrier for anyone to create "powerfull property tree". 3. Others: * basic_string should not be hardcoded. There are too many string implementations floating around. * Optional MT safety may be added. * Named template parameters may be used to deal with large number of traits * Preserving comments and whitespace in INI/JSON/INFO could be the /most/ important reason someone decides to use the library. * The library should be able to read multiline data that do not require backslash at the end. It would be usefuul e.g. to store scipts inside configuration. * The comand line parser should have reference to PO and should clearly state its limits. * It is possible and useful to extend the registry parser (registry_ptree?). One existing registry library can be found on: http://synesis.com.au/software/stlsoft/help/group__winstl__reg__library.html * The property tree itself may be serializable as it could be part of larger application state (this is different from using Serialization as engine for PT). * Support for various Unicode encodings (frex reading UTF16 BE and converting the strings to ANSI, all transparently). * Overloads for parsers to parse given memory block (e.g. mapped file, shared memory) * An user defined datatype (e.g. boost::any) attached to each node may be useful when one is content with the ptree data structure and doesn't want to move it from/to C++ structures. Features that I do not consider as needed: --------------------------------------------------------- * Transformation from one format to another. Unless this capability is naturally present in the library the tool should not get more complicated because of it. * Validators, type safety checkers, notifiers etc. Usefulness for the 80% of real world applications is IMHO the main selling point and I am far from sure whether these features could be implemented without sacrifying current simplicity. * Genericity for sake of genericity. Purpose of the lib is to read configuration data with least of hassle and then get out of way. It is not Boost.Tree (and should not be documented as if it is), it is not Visitor, it is not in memory database. * I would be very cautious with replacing parts of the library with Serialization / Multi-index. There are many practical consideraration - compilation time, supported compilers, projects with multiple executables, versioning. People using the library just want it to work and would not be willing to solve possible problems related to other libraries or even debug through 3pp libraries. * Breaking library to parts. This is just a way to tell intended users: "you'd better to quickly hack up something by hand, don't bother with PT". /Pavel