2,561
edits
Simplifying Aircraft Deployment: Difference between revisions
Jump to navigation
Jump to search
→Possible Steps
m (→Possible Steps) |
|||
| Line 31: | Line 31: | ||
# Delete (Uninstall) | # Delete (Uninstall) | ||
Installation involved checking if the aircraft exists (better to pull the list of available aircraft to allow user selection). We should check for version compatibility of the | Installation involved checking if the aircraft exists (better to pull the list of available aircraft to allow user selection). | ||
== Version Tracking == | |||
We should check for version compatibility of the installed FlightGear binary (as of 03/2008, the FlightGear binary fgfs doesn't yet provide any sort of version information). If an aircraft is not compatible with the current version of FlightGear, do not allow the installation of it. | |||
Regarding compatibility between aircraft and fgfs binaries, it is important to keep in mind that so far FlightGear doesn't provide any reliable way for aircraft authors and other contributors to determine what version of FlightGear they're running, or which features are supported by a binary. | |||
In fact, currently the only way for aircraft authors to account for different versions of FlightGear (and thus different feature sets) is to provide separate *-set.xml files, so that users themselves may explicitly chose the right ones (or fail to do so, for that matter). | |||
Basically, so far only the base package provides very basic version information, which is however only marginally representative of FlightGear's overall version (i.e. think about FlightGear pulled from CVS/HEAD, where each day features and resources may added, re-implemented or even removed, without such changes being communicated to possible dependencies (aircraft). | |||
This would also be an important factor because of FlightGear's irregular release cycles. | |||
Thus, the most promising approach to address overall versioning requirements in the context of FlightGear resources might be to tackle this issue from a feature-centric point of view, where the presence (or absence) of features is simply communicated to FlightGear resources by tracking corresponding properties within the property tree. | |||
This could for example take place by including a "features.xml" file from "preferences.xml", which would contain contents similar to: | |||
<PropertyList> | |||
<feature-support> | |||
<core> | |||
<has-osg-support type="bool">true</has-osg-support> | |||
<has-precipitation-support type="bool">true</has-precitipation-support> | |||
<has-shader-tree-support type="bool">true</has-shader-tree-support> | |||
</core> | |||
<fgcommands> | |||
<has-toggle-command type="bool">true</has-toggle-command> | |||
</fgcommands> | |||
<animations> | |||
<has-pick-animation type="bool">true</has-pick-animation> | |||
</animations> | |||
</feature-support> | |||
</PropertyList> | |||
So that relevant feature set modifications would simply be "communicated" by having contributors use fgSet("/sim/feature-support/...",true) and additionally edit the corresponding XML files. This way, it would be fairly easy for aircraft authors to sort of "query" the binary for its capabilities and feature support. | |||
Updating an aircraft involves checks if the aircraft is installed and then comparing the installed version with the latest version on a server. if the versions are the same, alert the user that the versions are the same and no update will occur. | Updating an aircraft involves checks if the aircraft is installed and then comparing the installed version with the latest version on a server. if the versions are the same, alert the user that the versions are the same and no update will occur. | ||