Proposals:Architecture related

This article is a stub. You can help the wiki by expanding it.

This is meant to become a summarized list of all feature requests/suggestions related to improving FlightGear's architecture, it is largely based on Feature Requests / Proposals / Ideas (where all related items were deleted) and may not be up to date with the most recent developments in CVS, your help in updating and maintaining this list is appreciated!

• The current Property Tree code is not thread safe, sooner or later it may come in handy if this feature was added (FWIW, threaded PropertyTree implementations are provided by these two open source libraries: poco boost) Note: the likely merits of this step are disputable at best (see: Modularizing, parallelizing and distributing FlightGear.
• Meanwhile, FlightGear has become a pretty monolothic piece of software, in the long run it would be desirable if the code could become somewhat more modularized and structured, eventually this should also make it easier for new contributors to get started.
• basically all subsystems should be fully "suspend-able" and "reinit-able" at runtime, there are currently various subsystems that will consume CPU cycles even though they are not in fact necessarily required, affecting FlightGear's performance negatively. This is particularly the case for non-SGSubsystem based systems.
• extend sgsubsystem class to optionally publish each subsystem's actual update interval (determined at runtime) to a specific property, this will allow simple nasal scripts to deal with any issues (i.e. show warnings) if a certain subsystem is not, or cannot be run at a certain update interval. As more and more complex subsystems are getting added to FlightGear this would add the possibility for automatic detection of subsystems that cannot be run at proper update intervals, i.e. due to old/slow hardware. Ultimately, this could also make it easier to add auto-scaling support to FlightGear. [1]
• eventually, it may become desirable to add unit testing support to those FlightGear subsystems/components that can be considered stable and that are thus unlikely to change significantly anytime soon, that way it should become much easier to track development problems early.
• More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim) would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily. [2]
• Extend the RenderTexture class to provide support for Frame Buffer Object based rendering to a texture, this is a relatively new way to support rendering to texture for platforms or OpenGL (driver) implementations that do not offer native RTT support, as it is the case for many older Linux cards: http://openvidia.sourceforge.net/fbo.shtml things like this are now internally handled by OSG