Aircraft deployment
| This article has been nominated for deletion since 16 November 2024. To discuss it, please visit the talk page.
Do not remove this tag until the discussion is closed. Reason for the nomination: This article contains out of date information and may not meet the quality standards of the wiki. |
Package Validation
Some form of package validation would be really useful, i.e. to resolve all file names/paths and come up with a dependency list. Also, case-sensitivity should be checked for, and dependencies to Nasal modules. For aircraft that are to be included in the default distribution, such as the c172p, we may also want to check for criteria listed at Release:Aircraft Selection Criteria.
Proposal from James
(Other proposals are welcome)
- An aircraft release is packaged into a .zip, possibly with a renamed file extension - the zip is exactly the current aircraft directory, including the -set file and thumbnails. The -set file is augmented with extra metadata field as required - especially license, version and variant, but hopefully other data values to allow richer launcher GUIs - eg data about aircraft manufacturer, era, usage.
- The zip file is placed on a publicly accessible web site/server
- A web-app running on a controlled machine accepts the zip URL via a form, grabs the zip, runs any checking scripts as desired (eg, author, license, rating metadata is set, thumbnails exist, etc, etc - potentially it could validate XML files, ensures textures are in a particular format...). The metadata and core parts of the -set.xml are slurped into a combined 'catalog', along with all the other aircraft versions and variants the web-app knows about. (Possibly we generate one catalog XML file, possible several, to be decided).
- The aircraft-manager tool/library/code has a list of feed/catalog URLs, which it polls daily (or when prompted) to download. (Assumes HTTP cache-ability on the catalog files is set sanely). Based upon this, the aircraft-manager can display any nice UI of aircraft filtered on any metadata, rating, license, etc, etc, and provide a 'click to install' button, or 'upgrade all installed aircraft' feature.
- The aircraft manager downloads zips from the original hosting URL, provided as part of the catalog. Presumably the catalog includes an MD5 sum to avoid nasty hacks. Crucially this means the web-app is not serving aircraft zips - they can be on S3, a personal web-host, or anything. Once the zip is downloaded the aircraft manager extracts it, and fgfs is ready to use it.
- Optional - totally separate to the client-side part, the FG website can use the catalog files to provide a nicer, automatically maintained aircraft directory.
Commentary
The goal here is that making an aircraft release consists of taking the complete folder, updating the -set file with some release-specific info, especially the version field, and maybe a change entry, uploading the .zip to some hosting, logging into the webapp with a privileged user name, and telling the web-app to retrieve the new zip. Separate to the version field, multiple variants will be supported, so stable and development versions can exist concurrently.
It's assumed anyone can run their own hangar, by running the web-app to create a catalog of their aircraft - or a group of them. So In the client GUI, you'd pick various catalogue feed URLs to subscribe too.
If the metadata includes compatible Flightgear versions, the aircraft-manager can filter the catalogs based upon that, so 1.9.1 or 2.0.0 compatible aircraft can be retained (on their web hosting) and still be available to those versions.
In the future, fgfs could process the compressed .zip files directly, by modify the file-loading code to use an alternate streambuf backend. This is non trivial.
For live development, the system could also accept other delivery mechanisms besides HTTP+zip, eg SVN or Git. This would mean changing the web-app to support other forms of importing - easy if the -set file can be exposed via an HTTP interface and polled periodically - and for the client-side parts to support the same download mechanism. However, since fgfs will continue to work with exist features, it's probably simpler in that case just to use svn or Git directly for that aircraft, and load it via --fg-aircraft!
(Keeping in mind the aircraft-manager tool has to run on Windows)
To Be Decided
- Handling of shared aircraft resources, i.e the current 'Generic' and 'Instruments-3d' directories, and hopefully more shared assets in the future. Problem here is versioning, if aircrafts X and Y require incompatible versions, we'd need to switch the shared package automatically.
- Handling of 'AI models' - whether these should be packaged inside the aircraft zip, or a separate kind of package, or something else again
- Handling of multiple -set files in a single aircraft dir, i.e light-weight variants. Probably the system can simply be designed to deal with a single archive providing multiple aircraft variants - so long as the set files are consistent with each other