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
