Hi, 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 interested. cheers Jim ------------------------------------------------------------------------- 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. http://sourceforge.net/powerbar/db2/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
