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
>> 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
> 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
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
- 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
[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
[ala boost.iostream filters for zlib...]
- string/separator/paths (see other postings in this thread)
- possible merging/interaction with proram_options library