Curtis Olson wrote: > I agree that the property system is for generic data ... so adding > color_vectors or position_vectors is really out of the scope of what it > should be intended for. This is too specific and I agree that it > creates a mess and there's then no good place to draw the line when the > next person comes along and wants to add some other specific aggregate > structure. > > However, if the proposal is to add support for storing generic float (or > double, or int) arrays in the property system, then I think that could > be supported. Again we already support character arrays (although as > has been pointed out, without an interface to be able to access > individual elements of the array.) > > Two misconceptions I am hearing, and maybe Tim can respond to these: > > 1. Adding float arrays to the property system for the purpose of > representing colors and vectors will require all modelers to convert all > their existing models, structures, and code to the new system. There > seems to be a lot of push back from modelers based on this fear, and I > wonder if this is going to be the case? If so, then they have a point. > Is this a misconception of Tim's proposal or not? It's certainly not a part of my proposal. I don't intend for a single line of XML in any model file to change. Eventually there may be a need to directly set effects properties from Nasal code included in models or have properties that "connect" to effect properties, but that is certainly way down the line. > > 2. Adding float/double arrays to the property system will also require > adding a myriad of operations on those arrays ... do we need to now > implement a full suite of vector and matrix math operations inside the > property system. I don't see why that would be necessary. > > I just want to keep the discussion clear and make sure that we are all > on the same page with what we are talking about here. I sense that a > large amount of negative imagination is creeping into the discussion, so > let's clarify if these fears are founded or not? > > Regards, > > Curt. > > > > On Sun, Apr 5, 2009 at 9:19 AM, 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. > > 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 > <http://www.zoner.com/ww-en/photo-studio-professional/>. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > <mailto:Flightgear-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > -- > Curtis Olson: http://baron.flightgear.org/~curt/ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
