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