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.



Flightgear-devel mailing list

Reply via email to