Re: [boost] Property Tree library review

From: Darren Cook (darren_at_[hidden])
Date: 2006-04-28 18:19:33

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_at_[hidden]> 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
> 
>