Hi, So, since I wanted to get in touch with you anyway ... Good to hear from you!
On Friday 26 June 2009 12:09:48 Petr Gotthard wrote: > I'd like to bring up again the issue of standalone FlightGear modules > (add-ons, plug-ins). You probably hear this question once a while, but I > have a new argument. ;-) > > Although the FlightGear design fairly modular it's provided as a single > binary. Everyone who wants to create a new I/O module must patch the > FlightGear sources and compile the FlightGear binary from scratch. This may > discourage those who want to use FlightGear as a tool and extend it in some > way. Moreover, it's not always possible to include all functions in a > single binary. Some functions may be mutually exclusive. > > I'm building a FlightGear interface for M&S HLA simulations > (http://virtualair.sourceforge.net/flightgear.html). There is a single > standartized C++ API, but many HLA infrastructure (RTI) implementations. To > use a particular HLA RTI it's necessary to re-compile and re-link > FlightGear against a particular set of libraries. Thus there can never be a > single "HLA compliant" FlightGear binary. > > To follow the "do things right" rule I think it would be great to implement > a generic interface for standalone I/O modules. Both Micro$oft FSX and > X-Plane have such interface. The M&S HLA users would just need to build a > shared module (.dll or .so) for a particular HLA RTI and load it via the > standard FlightGear plug-in interface. So, as far as I knor HLA/RTI, your problem is divided in two parts: 1. The problem with different RTI implementation libraries. 2. The problem with different fom's Regarding the RTI libs: As far as I can see the RTI c++ interface is defined in a way that you do not need to recompile anything. Everyting is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. For the case that a particular RTI implementation does not follow this rule, you need to compile flightgear explicitly for this particular library. I believe that this is accaptable. Regarding the different foms: I have seen your implementation and what I believe we can do more generic. Sure there is a part of your implementation that hard codes some attribute names of the foms into the binary. But this could be done in a more generic way, so that you can configure the attributes meanings at runtime instead. With this model, your two hardcoded implementaiton stubs for the those two fom's will be just a special configuration using the same c++ implementation. I for myself would like to have such a flexible implementation at hands. So all together I would prefer to include a more generic HLA/RTI implementaiton in flightgear than introduce a plugin mechanism. Greetings Mathias ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
