Re: [Flightgear-devel] [RFC] Dynamic plug-in interface for I/Omodules
Hi, So sorry for the long delay. On Wednesday 01 July 2009 16:29:23 Petr Gotthard wrote: > 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. Ok. > >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. > ;-) Well, I have code here that would at least cover those cases that you have already hard coded in your two fom implementation backends. As soon as I have something ready to try I will send that to you. I am sure that such a thing is much more convenient to use with different foms than something you need to recompile. Regarding the different binaries, you will just need to have so much versions of flightgear compiled from the same source and with different rti's available than you have RTI's. And since changes in the handling of FOM's would not need a recompile at all, I can think of this being also more convenient for your use case. > >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. Not sure about that. I expect to have something in the not so far future. Greetings Mathias -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ 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
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
>> 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] [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. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- ___ 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: > 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) 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. Erik -- ___ 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 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. > >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
