Good morning, this is yet another mail in support of rethinking the current proposal:
All the mentioned features regarding XML based shaders support are indeed very much desirable in FlightGear, but the proposed changes and approach, as well as the posted snippet of XML effects in particular, just don't seem in line with long-standing and proven FlightGear conventions or the modular design and implementation of the original property tree code in the first place. This applies in particular because all of the desirable functionality can apparently be implemented by using existing infrastructure and conventions, as has been demonstrated by various postings illustrating viable alternative and even better approaches using the existing API and conventions. But also because this proposal doesn't seem to really directly improve or benefit any other FlightGear components, which raises the question if implementing support for new primitive types in the global, system-wide property tree really is a good solution in this case? This also seems questionable because it introduces changes (namely new primitive types) to the property tree system that appear highly subsystem-specific, and irrelevant to or even incompatible/unsupported with the rest of FlightGear? Wouldn't these properties be highly specific to just one component and use in FlightGear (unlike any other feature of the property tree)? Wouldn't this create additional baggage in the property tree code that is not even remotely useful in other areas of FlightGear? Wouldn't they create yet another way of doing things [no matter how concise]? So it really appears to boil down to enhancing a proven and central FlightGear component with support for new types in order to accommodate the "needs" of one particular FlightGear system. The most often cited "reasons" I could find were: "I find the sytntax way too verbose for simple aggregate properties like colors." "More concise syntax for aggregate values" "I think XML is way too verbose" "I just want to evolve the very useful property system to support the syntax I like" It seems, all previously posted technical arguments (atomicity of updates and performance considerations) were shown to be addressable by using a more conventional approach, using listeners and tied memory? So is this really not just about syntactical sugar? What real technical advantages are there (apart from the more concise syntax), advantages that are not just specific to one specific feature or component and that are not addressed by any of the previously suggested alternatives? 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
