Property Tree Future

But from my point of view the property tree is also used as a reflection framework to reflect objects state into the models/scripting/whatever. From my point of view, the serialization of the objects into xml is just a special case of that reflection stuff. Given that, you might consequently want to reflect more complex types by the properties. — Mathias Fröhlich

I have a long, long, long term plan to improve multi-threading support, by enforcing subsystems to *only* communicate via the property tree, which has light-weight locks thanks to some work by Mathias. With a dependency graph between subsystems (which I want to add for other reasons any way) it would then become possible to run any 'clean' subsystem on a pool of worker threads (maybe just one, maybe more). — James Turner

I even believe that aggregates and more sophisticated types will be something good to have. — Mathias Fröhlich

Hmm, I have thought several times in redoing the property implementation in a more 'orthogonal' way. That would allow for such extensions in a natural way. Also from what I currently work on the HLA component seperation, a more flexible property system might allow me to greatly reduce the communication load on the HLA server. Also I believe that we can make that property system a little faster and more clear in its semantics I guess. We already have several too special cases there which I hope to clean up. [...] What strikes me with the property system is the lack of composed datatypes that in some cases need to set in an atomic way. The scalar world of the current property system where we have scalar accessors for the components of a composed datatype, we have several partial updates that will leave the object that is accessed by the property system in an partially updated state until the last update happened. Having compound atomic types like a vector for example solves that problem. [...] what I am also concerned about is the use of property listeners to work on osg's datastructures. I believe we should not intermix code paths that can happen during the application/update phase with the osg scenegraph structures. Think of the multithreaded viewer we are talking about with Curt. I would prefer to separate these steps in a way that we could also streamline the data flow somehow. With these listeners we change things in the viewer directly from the application step I guess. I believe that we better think of such a simulation as a pipeline that starts with the users inputs (joystick and such) the data is put into the simulation (FDM, instrument simulations, etc ...) the data is then put into the viewer's scengraph, which itself is used to render things that appear on the screen.Separating these steps with clear points in this pipeline where data is moved from one stage to the next would provide the ability to do these steps mostly in parallel (even more, we could do independent simulation entities in parallel). But fiddling with listeners here can make the first pipeline steps modify the data of the last pipeline step - which adds the need for either locks or if we do not lock, we stick even tighter to an application step that cannot run in parallel to the viewer stages. — Mathias Fröhlich