Actually, I don't disagree with any of the points you are making - however, given that the *-set.xml is already parsed by default, you could have the best of both worlds just by supporting the include directive, too.
That would allow people to keep their status information separate, so that it can be easily copied, shared and reused by others.
I never meant to say that the *-set.xml file shouldn't be parsed anymore. Honestly, if the goal is wider adoption of the new rating system, it simply has to be as simple and straightforward as possible. Some of the more experienced FG users and developers tend to forget the user experience every once in a while (myself included).
The new rating system is an important step in the right direction, but it's just scratching the surface:
Both of us know that FlightGear's flexibility also causes some new challenges, the PropertyList-encoded XML format is widely flexible, especially due to features like the include attribute and parametrization, but it's sort of non-trivial for new users to understand how things are hanging together. How could they possibly understand? There simply is no standard way of doing things.
Bottom line being, in FlightGear it really doesn't matter at all where certain markup is stored, as long as there is one single *-set.xml file, you could basically go pervert and store each property/XML node in its own dedicated XML file and just include all files - however that would obviously add to the obfuscation unnecessarily.
There are new challenges caused by FlightGear's "flexibility" - for example, it isn't straightforward to provide an aircraft/instrument panel editor, simply because it really doesn't matter at all how certain files are named, where tags are stored, how aircraft-specific Nasal files are loaded and so on.
The thing to keep in mind here is that just because FlightGear is so extremely flexible, doesn't necessarily mean that we should make "overly creative" and excessive use of this very flexibility: We don't want FlightGear to become obfuscated due its intrinsic open nature, do we?
For instance, just have look at the way FlightGear aircraft are increasingly structured in $FG_ROOT/Aircraft (see
http://wiki.flightgear.org/Standard_aircraft_structure ). As you know, there is absolutely no technical requirement whatsoever to structure files and folders like this. Yet, it does make things easier and more intuitive. And people sort of arrived there by duplicating what others did.
It is for a reason that most aircraft share a pretty common file system layout: we as human beings are better at dealing with it this way. It is out of question that we could dump all XML markup and even Nasal code into a single file, but it doesn't add to the clarity and self-documenting nature of FlightGear as an application and framework at all.
Basically this is all about "convention over configuration":
http://en.wikipedia.org/wiki/Convention ... figurationAs another example, have you recently had a look into $FG_ROOT/preferences.xml ?
That's another excellent example for a
huge XML file that could be EASILY split into a number of separate XML files that could be simply referenced from the top level preferences.xml via an include directive, so that the defaults could be stored separately - i.e. in $FG_ROOT/Preferences or $FG_ROOT/Defaults
You would end up with separate XML files for all important setting:
- $FG_ROOT/Preferences/startup.xml
- $FG_ROOT/Preferences/rendering.xml
- $FG_ROOT/Preferences/sound.xml
- $FG_ROOT/Preferences/systems.xml
- $FG_ROOT/Preferences/views.xml
- $FG_ROOT/Preferences/multiplay.xml
- $FG_ROOT/Preferences/terrasync.xml
- $FG_ROOT/Preferences/controls.xml
- $FG_ROOT/Preferences/instrumentation.xml
- $FG_ROOT/Preferences/logging.xml
and so on
It's not that the current technique would be bad, it's just that it isn't as intuitive and self-documenting as possible.
I don't know if you agree or disagree, but I can assure you that if you do disagree, then it's because you are also a long-time FlightGear user and developer with plenty of experience
Finally, I do know you know for yourself that one of the more frequently asked questions on FlightGear is about creating new aircraft, our standard response is usually to start modifying existing aircraft step by step and then take things from there by referring to other aircraft and the "documentation".
Yes, we do have some basic info to get people started:
http://wiki.flightgear.org/Howto:_Make_an_aircrafthttp://wiki.flightgear.org/Standard_aircraft_structureHowever, the truth is we could also do better here, just by providing a set of boilerplate files in a predefined default structure (maybe even as part of the base package), so that new aircraft developers could simply populate all important files, without having to understand all of the markup in one single *-set.xml file.
Just imagine a "dummy" aircraft folder that new developers could copy and customize by following conventions and guidelines.
If you disagree again, just take a look what the "Linux Standard Base" is all about:
http://en.wikipedia.org/wiki/Linux_Standard_Base It is always much easier to understand one small self-contained portion of information that is following well-defined conventions, rather than having to browse and filter through plenty of irrelevant information.
Really, we don't need to agree on this, and even if you should feel inclined to invite me now to "scratch my own itch" to prove my point: I am not at all affected by this and I honestly don't believe this can be tackled by a single person, it'd require wider community effort; you have seen for yourself how long it took to "implement" the new rating system, including dozens of lengthy discussions and a number of sizable wiki articles over 5+ years.
I guess that goes to show the weaknesses of open source