Gennadiy Rozental wrote:
"Marcin Kalicinski" <kalita@poczta.onet.pl> wrote in message news:e2bn7h$s8v$1@sea.gmane.org...
Make up you mind finally. What is your library?
1. Runtime parameter facility 2. Permanent storage facility 3. XML parser
I'm afraid it is all 3, plus some more. By "some more" I mean it has more parsers than just XML, and it can also be used to manipulate hierarchical, human readable data structures at runtime.
And that's the main problem with this submission. Instead of clearly specified problem domain and design that address issue in this domain, you present some mixture of half-good components each with unclear advantages over existing dedicated solution in each respective area. I want faster search or no search at all - no can do.
There is the possibility to rewrite the internals of property_tree with Boost.MultiIndex, and then it could use a hash-index instead internally. Why is having no search so important. How does it hurt you that it is there? (if the small overhead is not important anyway)
I want different some versioning support for permanent storage - no can do.
What does this mean? versioning ala boost.serialization? (aside: I think it would be reasonable for ptree to be serializable)
I want some automatic validation and conflict resolution - no can do.
What does this mean?
I understand it's good enough for you. But this is just the choices you made. Coupling solution for independent problems under the hood on one library is the source of inflexibility and unacceptable for boost IMO.
We can also keep adding customization to a component until it suddenly collapses under its own weight. Gennadiy, I hope we can avoid too much flame-wars. And I hope we can to the buttom of the problems you mention s.t. you also would want to use this library (unlike PO). -Thorsten