2,561
edits
Simplifying Aircraft Deployment: Difference between revisions
Jump to navigation
Jump to search
m
markup requirements
m (adding related RFE item from fgrun tracker) |
m (markup requirements) |
||
| Line 83: | Line 83: | ||
# Optionally report back to the launcher that the sub process is done. | # Optionally report back to the launcher that the sub process is done. | ||
# Sub process exits. | # Sub process exits. | ||
= Requirements = | |||
Regardless of whether an aircraft needs to be installed, updated or deleted, there's a common set of requirements that need to be satisfied in order to implement support for these actions: | |||
Preferably, each aircraft *-set.xml file would reference a separate XML file detailing its own structure (folders and files, in the sense of "META-INF"), such a list of files would enable future aircraft maintenance routines and arbitrary frontends to easily determine an aircraft's internal dependencies. | |||
So that pristine state can be ensured, and possibly critical actions are only performed under valid circumstances (i.e. unaltered state). | |||
In addition, it might make sense to consider using checksums or hashes of each aircraft-specific file to track possible modifications (and thus avoid possible accidental deletion of modified files). | |||
Such an XML file would contain sufficient detail to enable installing, updating and uninstalling aircraft. | |||
Due to the possibly dangerous nature of such actions like updating and uninstalling (deleting), users would preferably never directly conduct such operations on the base package, but rather a user-specific aircraft directory, possibly within ~/.fgfs/User-Aircraft. | |||
Relevant information would among others comprise: | |||
* filename | |||
* location of file | |||
* hash of file contents | |||
* folders in aircraft directory(?) | |||
In XML, this information might be represented in the following form: | |||
<PropertyList> | |||
<Aircraft-Files> | |||
<file name="aircraft-set.xml" location="$AIRCRAFT_FOLDER" original-hash="......"/> | |||
<file name="foo.rgb" location="$AIRCRAFT_FOLDER/Textures" original-hash="......"/> | |||
<file name="sound.wav" location="$AIRCRAFT_FOLDER/Sounds" original-hash="......"/> | |||
</Aircraft-Files> | |||
</PropertyList> | |||
Such files could be created and maintained automatically for each aircraft by using a corresponding perl/python script that would allow contributors to easily create, edit/update and remove entries in such files, so that hashes are automatically updated, too. | |||
Having such a file available, the actions of installing, updating and removing aircraft in a custom location would boil down to: | |||
* Install | |||
** integrity check: iterate over folder contents to ensure pristine state, i.e. all referenced files must exist and their hashes must match, if they don't: cancel | |||
** ask for customization options (i.e. new location) | |||
** check if location exists and is writable | |||
** if ok: foreach referenced file, create corresponding folders and copy files, validate results (compare) | |||
* Update | |||
** integrity check, as above | |||
** ask for custo | |||
* Uninstall (Removal/Deletion) | |||
** ask for customization options (i.e. folder location & aircraft) | |||
** check if location is writable | |||
** integrity check | |||
** if untouched: iterate over referenced entries and unlink | |||
** if not untouched: warn, show differences and offer "force" mode to remove those files known and referenced | |||
= Related Mailing List Discussions = | = Related Mailing List Discussions = | ||