hf...@inmail24.com wrote: >> 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. > I agree that the property tree system performs this IPC role well. The effects properties don't live in the global property tree and so won't introduce any confusion in this area.
> 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). If a subsystem can't parse a property, chances are good it doesn't need to worry about it... Unless you are talking about systems that deal with properties in a generic way, which you list below. > > 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. These are complex systems? My proposal addresses how Nasal can deal with the new properties -- as arrays -- and my initial code implements that. My initial code has modified the XML property reader and writer. Not a big deal. I admit that I haven't looked at the telnet interface yet, but I don't think it's too different from the property browser, which I have changed in my code. The multiplayer code does not depend on arbitrary property types; the properties and their types are all hard-coded. > > 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. I'm not proposing to introduce my new types into the global property tree or change any existing properties. However, if the new types prove useful, they will hardly be second-class. > > 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. I wasn't around for the birth of the property system, but I would imagine that it has evolved to meet new needs... > > 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. And not very likely. > > 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)? It seems to me that you are afraid of any evolution of the property system, and I'm not sure why. Surely subsystems that communicate using properties must agree on their names and semantics; the concrete type of the property is just a detail. The systems that generically deal with properties have been or can be changed as necessary. But all this assumes that people will start going wild with new property types. That's not part of my proposal :) Tim ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
