SGModule - standalone SGSubsystems

Caution  Developer information: Some, and possibly most, of the details below are likely to be affected, or even deprecated, by the ongoing work on implementing and improving HLA support in FlightGear. For recent updates, please refer to HLA Timeline. Please see: High-Level Architecture for further information To avoid conflicting efforts, you are advised not to start working on anything directly related to this without first coordinating your ideas with FlightGear core developers using the FlightGear developers mailing list. talk page..

Background

Increasingly, FlightGear developers are talking about splitting up the FlightGear design such that it may use multiple processes or threads for particular subsystems (i.e. using the ongoing HLA work: FlightGear HLA support (High Level Architecture)), this requires a subsystem design such that certain subsystems can be optionally run as different threads or processes, possibly using different binaries or the same fgfs binary (started in a different startup mode), while still being 100% compatible with the standard way of being run in the sequential FG main loop, as a SGSubsystem.

The FGPanel project illustrates some of the issues and challenges related to duplicating parts of the FlightGear code base in order to run parts of FlightGear in a standalone fashion, with the Canvas subsystem being a more recent example of a subsystem that shall eventually support a standalone runtime mode:

We need to find a clever system to come up with some interface class like SGSubsystem
that can be run in standalone mode, something like "SGStandalone" - which implements
the full SGSubsystem interface (subclass), but which can also be run directly 
in a non-fgfs main loop, with just the subsystems required by the corresponding subsystem
- for the canvas, this would probably mean looking at the fgpanel code: XML processing
(private property tree) and a network connection to the main FG process, so that 
properties can be exchanged and updated.

Initially, it would probably be easier to introduce a specific command line argument (or even just a property like --prop:/startup-mode=foo) so that FlightGear doesn't run the main initialization, but just initializes a particular module which is designed to be run in a standalone fashion.

Basically, you would start FG using a specific switch like ./fgfs --startup-mode=canvas Initially, this could be implemented with a custom property: ./fgfs --prop:/startup-mode=canvas

This is also the approach taken by the google chrome and firefox browsers: the same binary is used, but different startup modes are used.

The bootstrapping code (fg_init.cxx) would then need to be modified to disable all the unneeded stuff, and make FG start up without FDM, SOUND etc. and just run a single SGSubsystem (Canvas) in the main loop.

Ideally, it should be possible to also link subsystems as standalone binaries, so that the linking/library dependencies of the main fgfs executable are not automatically inherited to modules which may not need all of the FG libraries, so that modules like the FDM or the Canvas don't automatically link in OpenAL or OSG dependencies.

Objective

Establish the requirements to implement an abstract interface that satisfies the standard SGSubsystem interface, while allowing such subsystems to be run as different threads or processes, using the same code base, and supporting the code to be run as part of the same fgfs binary, while providing an option to create separate binaries for specific modules, so that these don't introduce any unneeded fgfs-related dependencies.

The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example. — Mathias Fröhlich (FlightGear Devel mailing list)

References