Simplifying Aircraft Deployment: Difference between revisions

Jump to navigation Jump to search
m (adding library notes WRT accessing archives like directories to facilitate running aircraft w/o having to install them in the first place)
Line 69: Line 69:
''Note:'' While explicit versioning (in XML files) may be one way to tackle the compatibility issue, another one might be to to read in both *-set.xml files and directly compare the resulting SGPropertyNode* structure, this could tell if the XML contents are identical. To do the same for resources included via XML files (i.e. textures, sounds, 3D models etc), one could calculate a simple CRC of each included file.
''Note:'' While explicit versioning (in XML files) may be one way to tackle the compatibility issue, another one might be to to read in both *-set.xml files and directly compare the resulting SGPropertyNode* structure, this could tell if the XML contents are identical. To do the same for resources included via XML files (i.e. textures, sounds, 3D models etc), one could calculate a simple CRC of each included file.


== Deleting ==
== Deletion/Uninstallation ==
Deleting an aircraft is even easier as we may not need to talk to the server. Instead we check if the aircraft is installed and should check to ensure that there are no dependencies for the aircraft. An example of which is an aircraft that makes use of another aircrafts instruments and is not centrally installed.
Deleting an aircraft is even easier as we may not need to talk to the server. Instead we check if the aircraft is installed (and unmodified) and should check to ensure that there are no dependencies for the aircraft. An example of which is an aircraft that makes use of another aircrafts instruments and is not centrally installed. Preferably, aircraft would by default only be deleted/uninstalled if they match the following requirements:
 
* aircraft folders would reside in a user-specific location (i.e. $FG_HOME/Aircraft): to avoid possibly corrupting system-level FG_ROOT
* aircraft folder must be in pristine state/untouched:
** no removed files
** no edited/changed files
** no added folders
 
While deletion of modified aircraft folders seems possible, it would make sense to only offer this in some sort of "--force" mode, so that users are definitively aware of the fact that an aircraft has been modified, and possible changes would be '''lost'''.
 
By default, an uninstallation routine would only delete those files and folders that are explicitly referenced in a corresponding XML file if they match a given CRC or hash, this would help avoid cases where modified/new files may be ''accidently'' deleted by simply doing something like "rm -f $FOLDER".


== Extracting a new aircraft ==
== Extracting a new aircraft ==
2,561

edits

Navigation menu