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

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2006-04-21 10:39:12

Thorsten Ottosen wrote:
> Jorge Lodos wrote:
>
>> What I think PT must have that serialization library is not meant to
>> is:
>>
>> 1. The ability to load/save properties independently, not as a whole.
>> 2. A documented (for library extensibility) parser interface
>> allowing parser developers to accomplish (1).
>>
>> At least 3 storages requiring (1) come to mind: windows registry,
>> ISA Server storage and IIS metabase.
>> I would put these requisites as conditions for acceptance.
>
> I think it is quite hard to require that a parser for
> config file X must exists for us to accept the library. It puts a
> great
> deal of burden on the library author. Our focus should be on
> the general core interface of the library s.t. we get a flexible
> solution that can be useful in many areas.

Where in the documentation would one find that interface documented in order 
to review that aspect?

I think this ommision is what's leading to the perception that the library 
is an xml library, or a command line library, or a... That along with the 
fact that nearly 1/2 of the documentation deals with describing these 
specific parsers.

My vote on the current property_tree submission is NO. I think it could be 
re-submitted in the future given a clear rationale accurately stating:

- it's intended use
- a comparison with similar libraries (have you looked at McObject's 
ExtremeDb as one example)
- why/why not it's not based on boost.graph libray as a 
Directed-Acyclic-Graph
- why/why not it interacts with trees in spirit
  [Joel recently mentioned a fusion tree on the spirit mailing list]
- why would I not just use map< vector<string>, data > along with 
upper/lower bound
  [or a TST based map]

Without these the criteria required for review is a floating target.

Other specific issues needing to be addressed include:

- clear separation of the library from specific instances of it's 
use(xml/json/...)
  [ala boost.iostream filters for zlib...]
- string/separator/paths (see other postings in this thread)
- possible merging/interaction with proram_options library

Jeff Flinn