> Except for a few inconsistencies in xml style that already have been > mentioned I think it's worth adding it then.
Maybe I am misunderstanding this issue, but I have been involved in using FlightGear at work for a number of simulation related projects during the last couple of years, and to me some things are still unclear: Personally, my understanding of the property tree is that of an IPC enabling mechanism, that ties together all FlightGear subsystems and often also many non-FlightGear related tools/software even outside its own address space. So from my point of view, it is seems important to keep in mind that the property tree is not only about global variable storage but that it's also FlightGear's one and only standardized IPC mechanism, all subsystems and many FlightGear related tools that work outside the fgfs process space communicate with each other using the property tree and its natively supported types. With this in mind, it really seems of paramount importance that all property tree users (fgfs subsystems or external tools) have a concept and way of dealing with the native data types represented in the property tree. This exactly is it what makes the property tree, and more generally, FlightGear so intuitive, unobfuscated, powerful and easy to extend. This has been my experience when interfacing FlightGear to other software. Enhancing the property tree to support new component-specific native types that cannot be directly accessed, manipulated or processed by all or at least many other FlightGear related subsystems and tools seems like a troubling idea to me, in particular when it's not even foreseeable that other subsystems are going to develop a demand to also benefit from such a change eventually (just because they can already do all of this simply by using a more verbose, user-friendly and self-explanatory format that's been in use for years). Just think about some of the more complex systems that depend on having a full understanding of all property tree data and types, such as Nasal, the XML protocol system, the telnet interface to the property tree or the multiplayer system, all of which depend on working with arbitrary native property types. In its current form the property tree and its potential is virtually unrestricted and many new features were and still can be implemented on top of this very genericity without requiring modifications to the core implementation of the property tree. The natural tree-structure of XML and the natively supported data types allow users to emulate even complex data structures just by using the existing -admittedly verbose- syntax. But that's simply the cost of directly mapping XML to the key/value format used by the property tree. So the question really appears to be if FlightGear wants to end up with property types that are so purpose- and system-specific that only certain subsystems really know how to deal with them, essentially resulting in "second class properties" that cannot be processed by much of the currently existing FlightGear infrastructure? Basically, this is introducing a form of forced encapsulation into the property tree. I am not trying to dramatize this issue, this is just my current understanding of the likely repercussions. For the time being, the property tree system doesn't have a single feature (to my knowledge) that is really specific to just one single FlightGear component or purpose - the property tree code has been so well generalized that it can be equally used by all components, without restrictions. It just consists of primitives, building blocks that can be used to model more complex data structures on top of it. Changing this would probably not only result in second class properties but eventually also in second class subsystems and after some time also in second class software interfaces and tools, because not every property tree "user" may be able to deal with all of FlightGear's internals represented by such non-POD types. According to my understanding of the situation, this would be a very unfortunate situation. It seems logical and plausible from that from this point of view, this proposal would actually contribute to obfuscating FlightGear and degrading the current property tree system, which really is currently fully self-documenting and 100% open and accessible to all components. So adding new non-POD types raises not only the issue of inter-type conversions for such non-POD types, but also the issue of serialization for persistence/network transfer purposes (i.e. custom protocols, multiplayer). It seems to me, such additions may cause a whole new dimension of potential issues. It's obvious and understandable that, in the light of Tim Moore's very significant and highly appreciated contributions to FlightGear, it is very easy to overlook the potential architectural implications and ramifications in this proposal. Even if this is ultimately accepted for the time being: where is the line to be drawn? Are there going to be aggregate types that can be directly mapped to C++ data structures such as arrays, structs or unions? Or might there even be binary blobs one day in the property tree in order to directly store textures, audio files or 3D models and animations in the property tree? I'm sure there are scenarios where having support for something like that would be useful. And how are those non-POD types going to be serialized (i.e. for network or XML use)? Finally, it seems very likely that there are always going to be more aircraft-set.xml files than there'll ever be XML/effects files - if aircraft developers manage to cope with the verbosity of these aircraft-related XML files, they surely won't bother too much about some self-documenting explicitness in an XML/effects files? best regards -hfitz ---------- Get even more from your private email hosting service. Visit the pages of Zoner Software and download your free copy of the Zoner Photo Studio 11 program today! Learn more - www.zoner.com.
------------------------------------------------------------------------------
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
