One important part of our Software is a rather sophisticated "ParamTree" (that's our name for property_tree) which comprises all those facilities that Gennadiy suspected the property_tree to more or less focus on: - Runtime parameter facility - Permanent Storage facility - XML Parser (Because we want the format to be human-readable and also editable if need be) I'm not too happy with our ParamTree, so I couldn't wait for the property_tree, whose interface I believe to be elegant and concise. I wanted to redesign our ParamTree around the property_tree, with just a thin wrapper to cater for our following requirements: - The application is multithreaded, so access to the property tree must be thread-safe and iterators from different threads must not interfere (usually done by ref-counting techniques) - It must be possible to navigate towards the root of the tree - In case of acess errors, it must be possible to retrieve the name of the file, from which the data was loaded - The component must have an abstract base class interface I'm well aware that these requirements are not in the spirit of the STL, and would never want them to be part of the property_tree. What I usualy do in these cases is 1. Design the abstract interface 2. Code a small wrapper class that implements the interface with the aid of on aggreagated STL-compliant container, boost::mutex etc. When I sat down to do design such a wrapper for the property_tree, I realized I couldn't. Not because of a property_tree deficiency, so I think, but because of the very nature of the recursive tree structure: I can't have a single class instance with a property_tree at its core, but I would need an instance for every tree node/leaf. However, I have no idea how canI "inject" my own node type into the property_tree or conversely put a wrapper around every ptree? The only viable solution I see at the moment is to take the traditional approach of designing my own node class, that aggregates a multi_index container, a mutex etc. and looking for the most suitable xml parser for building up the tree. Our ParamTree's redesign would hugely benefit from Marcin's excellent ideas, but it would not be using property_tree; and suddenly, I'm in the camp of those who argue towards a boost::xml_parser, an improved multi_index etc., rather than towards a lean component that does it all. Can someone please help me and point out how to design a wrapper around a tree structure such as ptree? I could then further participate in the review based on my experience implementing such a wrapper. Regards Leif