Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/Omodules
Hi Mathias, Thank you very much for your comments. 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. The basic HLA standard (both DoD and IEEE variant) provides only a C++ API compatibility at a compile-level. There is a SISO standard that should assure dynamic link compatibility (DLC). However, some RTI libraries may not be compliant to the SISO standard. 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. Not for me. :-( 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've been thinking about this a lot. There is no simple mapping between FlightGear and FOM parameters. Sometimes it's necessary to translate units, geodetic/geocentric frames or perform other calculations. The generic mapping engine would have to be a very powerful scripting language like Nasal or Python. I've decided to start with a simple hardcoded interface and investigate all FOM attributes and interactions that may be supported by FlightGear/HLA. After we understand all possible features of the FlightGear/HLA interface, we will reconsider implementing the generic interface. Of course, unless somebody volunteers to implement it right now. ;-) 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. Yes, it would be nice to have a generic HLA/RTI implementation. From the cost-benefit ratio perspective, a plug-in mechanism will significantly simplify the use of the hardcoded interface, so the need for the generic implementation is not so urgent. And it's much easier to implement a plug-in mechanism, than the HLA/RTI interface. Best 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/Omodules
Hi, I'm (still) against binary runtime modules for FlightGear. And I respect that. 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. Yes, that is extremely generous. In fact, this allows me to implement the generic plug-in interface and distribute the modified FlightGear along with my binary runtime modules that are all under GPL. 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. In my opinion not all commercial entities are trying to rip off open-source software. Both commercial entities and GPL software can benefit from each other if they are all fair. Which is not always true, I know. :-( Best Regards, Petr -- ___ 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/Omodules
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. Erik wrote: 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. Let me advocate the idea: I'm proposing a generic interface. If you look from the other side, it's a possibility to easily implement a new I/O module for FlightGear. To help people that might be interested to extend FlightGear but do not want to recompile the whole binary. I personally believe that the number of nice users scared away is higher than the number of new GPL violating users. Especially because commercial/proprietary users may use X-Plane. Every coin has two sides: - Not every I/O module will violate the GPL - Not every nice (non GPL violating) user interested in extending FlightGear is able/willing to build the whole binary - Only some of the users will violate GPL - Generic interface simplify/facilitate FlightGear extensibility for all users (both nice and GPL violating) - People don't need the generic interface to violate the FlightGear GPL - The generic interface doesn't have to be included in the mainline CVS - Including the interface in mainline CVS helps all users (both nice and GPL violating) 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/Omodules
All valid points but irrelevant for the GPL. It is already possible to connect proprietary software to FlightGear using the generic binary (socket) protocol handler, but that doesn't violate the GPL. Plug-in interfaces tend to do because they are considered 'part of the program' by the GPL. Even in the case of a seperately compiled shared library or DLL? I have my doubts. GPL does not make shared libraries illegal. Creating GPL'ed libraries, connected to GPL'ed applications does not violate GPL. The GPL is violated if someone refuses to publish source codes of this library. I'm not proposing to use plug-ins with other license than GPL. Since FlightGear is GPL'ed, all plug-ins must be GPL'ed as well. This is out of question. I just propose to enable GPL'ed libraries to get connected to FlightGear without building the whole FlightGear binary. Petr -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Suggestion to make FlightGear multiplayer compliant with HLA
Hi Oliver, the HLA specifications (IEEE 1516) are not free, that's a disadvantage. However there are open-source HLA run-time environments (e.g. http://www.cert.fr/CERTI), so it's not necessary to implement whole new HLA run-time environment. Regarding the multiplayer in FlightGear I see two options: 1) Either to implement a FlightGear proprietary protocol for multiplayer with a gateway to HLA, or 2) to actually use native HLA as a multiplayer protocol. The solution 1) means a new protocol and a new server (updated fgms) needs to be implemented, but the implementation requires no IEEE standards and the solution doesn't depend on a 3rd party framework. The solution 2) doesn't require any new protocol nor HLA gateway to be implemented (HLA RTI will be used instead of fgms), but introduces an additional dependency on a 3rd party software. What would you think: proprietary fgms with HLA gateway, or native HLA? Best Regards, Petr __ Od: [EMAIL PROTECTED] Komu: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Datum: 04.03.2008 23:22 Předmět: Re: [Flightgear-devel] Suggestion to make FlightGear multiplayercompliant with HLA Hi Petr. I (as the author of fgms) would be pretty much interrested to implement fgms as part of a HLA infrastructur. What detained me from going that way is, that I found no free (as is free beer) documentation on HLA specifications and the quite complex structure (too complex for a one-man-show). Additionaly I'm not sure about license issues involed. Are we allowed to publish all parts of (our) HLA infrastructur under the GPL (which will kind of undermine cash-flow of documentation providers like the IEEE)? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Suggestion to make FlightGear multiplayer compliant with HLA
Dear FlightGear developers,(a short introduction first: I'm a newcomer to FlightGear, my professional profile can be found at http://www.linkedin.com/in/gotthard) May I ask whether you would be interested on striving to make FlightGear compliant with the US DoD High Level Architecture (HLA)? It could make FlightGear more attractive. I found that 1) several FlightGear multiplayer server feature requests at http://sourceforge.net/projects/fgms suggest to introduce - subscription-based property management - customizable set of propagated properties - more efficient data propagation mechanism - global status for date/time, weather, AI object positions 2) also the description of A New Architecture for FlightGear Flight Simulator proposes a distributed FlightGear architecture, which would allow all users to see the same AI objectshttp://wiki.flightgear.org/flightgear_wiki/images/1/1e/New_FG_architecture.pdf I believe that especially the HLA Declaration Management and Data Distrib ution Management perfectly match the above mentioned demands.Just look at Fig.2 in http://pagesperso-orange.fr/dominique.canazzi/paper.html. It's nothing that can be achieved in a few days, but I think it's feasible. To have a perfect solution we'd need to (probably in this order) - turn the FlightGear multiplayer server into a HLA RTI (run-time environment) - implement the multiplayer protocol according to HLA standards - factor out (extract) the non-aircraft objects (weather, AI objects, ATC server, etc.) to enable global status What is your opinion? I want to start developing a HLA RTI first, so (if you're interested) there will be plenty of time to discuss the requirements and architectural issues. One answer in advance: I've seen an idea to extend FlightGear to support the DIS protocol (a HLA predecessor and competitor). I believe that HLA is more suitable for this purpose because it implements Data Distribution Management. Best Regards,Petr - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
