Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
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 MS 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 MS 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
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
I'm (still) against binary runtime modules for FlightGear. They are an invitation for circumventing the GPL, locking in users, and potentially harm cross-platformness. I find the prospect of a vendor offering a new device with closed source libraries for stock FlightGear worrying, and even more so if there's only a Windows DLL, but none for OSX and all the Unices/Linux. (Not that I'd want to run any secret binary blobs on my clean machine.) We offer more possibilities than X-plane and MSFS and all the others put together -- by letting people look at/modify/redistribute our source code. For free. That's very generous, if you ask me. That linking non-GPL modules would be illegal, anyway, doesn't make the situation any better. Unless you can offer us a *lot* of money, time and personnel for filing lawsuits. Otherwise the GPL protection is rather weak and only theoretical. We shouldn't encourage corporate entities to rip us off. m. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
Melchior FRANZ wrote: I'm (still) against binary runtime modules for FlightGear. I'm more curious as to whether we need them. The entire guts of FlightGear are available to almost anyone via external communications (e.g. sockets) and Nasal. Why not write a communications script or Nasal script that exposes the data required for your add-on over a socket, and use a similar tool at the add-on end? There is no license that will ever state that any application that *communicates* with it (whether it be a TCP socket, file, or Unix socket) needs to adhere to that license as well, since that would pretty much be the ultimate enforcement of copyleft. Simply put, the mechanics for doing this with FlightGear are already in place, you only need to take a slight detour over a communications link. This has its advantages too, such as added security (no possible code injection) and inherent networkability. Downside is that it takes a little more brain-food to make it work. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
Hello, 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 MS 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 MS 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. If I discuss the design issues with you, implement and test such interface, would you accept such interface for the mainline FlightGear? Regards, Petr -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules
Petr Gotthard wrote: 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 MS 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. Adding a plug-in interface instantly raises questions about GPL compatibility which have to be addressed prior to implementing such a thing. I believe the question did come up several times before but the possibility to easily violate the GPL was always a too big a hurdle to continue. Erik -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
