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