Some discussions have already taken place on JSBsim devel mailing list 
regards communication between "modules" of flightgear.
My thoughts are that flightgear divides "naturally" into four major 
sub-system modules:
a) FDM (jsbsim is already "standalone")
b) cockpit input and output (ie joysticks/pedals/throttles/switches etc 
and displays/lights etc)
c) external view (with all the graphics rendering for 
forward/back/sides etc)
d) motion system (probably not many users!)
The main issue is inter-processor communication between modules ie 
between modules multi-threaded on multi-processor computers,between 
modules in processes on same computer,between modules in processes on 
networked computers.
I have been looking at the idea of using some database containing the 
property lists which would be read and updated asynchronously by the 
various modules at whatever frame rate is suitable for the module (not 
necessarily its "internal framerate")
My first thought was LDAP, although using a directory service as a 
database is often frowned upon!
I am familiar with OpenLDAP and it looks like an LDAP schema can be 
derived fairly easily from the property list or better still from the 
XML schema (maybe programs exist to do this already?).
There may be problems with data rates etc so maybe it will need MySQL 
or somesuch but that seems an overkill for the functionality needed.
The advantages of the database are that "proprietry" (ie FG/jsbsim) 
protocols are not needed as standards already exist and multi-process 
(many to one and one to many) synchronisation etc is already built in 
to the database API. Also there are the search facilities and other 
directory and database functions that can be made use of.
Also I have had a look at native XML databases and although it is nice 
to be able to write/read and search directly in XML, if they are based 
on JAVA (such as Opensource Xindice), they are pitifully slow compared 
with what is required (there is some interesting work published on the 
Web comparing native XML data base with MySQL with all its problems of 
representing the XML data).

We can experiment on various communication ideas without restructuring 
flightgear by simply running three instance (forget motion system for 
now!). One instance running FDM with no panel display and no outside 
view, second instance running no FDM or view and only panel, and third 
instance running no FDM or panel and only outside view.

An advantage of this modularisation and inter-process communication is 
that as flightgear is multi-platform we can select the optimum platform 
for each module even utilising RTOS where needed or maybe specialist 
graphics engines.

If anyone has any comments and other ideas etc I would be very 


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Flightgear-devel mailing list

Reply via email to