Back to the plugins discussion ... I am really about to get famous here for my unpopular views ;-)
Andy Ross wrote:
Boris Koenig wrote:
Erik Hofman wrote:
I'm still not convinced that a plugin system would be such a great idea for FlightGear.
Well, I am just making suggestion :-)
I think most of the criticism centers on the idea that, even if you had a nice plugin system available, it really isn't going to help you very much with doing extension development.
I was specifically thinking of things that would currently require to directly modify the FlightGear sources, in many cases it would be very useful to have the possibility to load an application dynamically and run it *within* FlightGear, think of applications like "atlas" - if there was a plugin interface available, it could easily integrate completely into FlightGear and would not need to be running separately.
Similar applications like flight planners or even applications that serve as flight management computers could also integrate natively into FlightGear.
One of the easiest ways to provide a very basic plugin interface would first make sure to provide handles to FlightGear's client area and subsystems so that each module/plugin can easily use these to do specific things.
This would not even be terribly complex and could still be pretty useful, e.g. a flight planner plugin would then simply need access to:
- FlightGear's client area
- FlightGear's Navaids dataThat way you could already draw your own GUI into FlightGear's window in order to display your flight planner tool which could then make use of all the necessary (navaid) data provided by FlightGear itself.
Of course something like that could also be implemented using a scripting language, but more complex applications would probably be also more time-critical and would need to rely on threaded design.
It doesn't change the existing Nasal or FGCommand interfaces at all,
well, of course I was thinking of a way to enhance that functionality, it shouldn't be that much of a problem to load a library which exports a C function and a function name for Nasal and make that C function then available as a Nasal or FGCommand, but maybe I am wrong here - but even without knowing anything about FlightGear's/Nasal's internals, I could come up with a corresponding example in ANSI C within 30 minutes... So, even if this _is_ really a problem in FlightGear (which I can't believe) one might still fall back to good old C/C++ - which would probably be the case anyway when it comes to dealing with pointers for dynamic function import.
and adds an extra layer of complication.
This is of course true, but that extra layer is compared to the FlightGear sources itself pretty restricted and would not be really complex. One could start to add a very basic plugin interface at first.
And it would be certainly _A LOT_ easier to document a simple plugin interface than writing all the documentation that's still missing for FlightGear.
You won't need that much functionality in the beginning - things like access to most of FlightGear's subsystems would probably already be sufficient in the first place.
That way a plugin could "ask" FlightGear to make use of a specific subsystem.
The idea of a "plugin" comes from the commercial software world, where distinct entities (Microsoft and aircraft vendors, for example) need to ship software on different schedules.
You're right - but plugins have other advantages that apply also to the non-commercial world, scenarios which you didn't yet mention, e.g.:
You can easily incorporate new functionality into a project like FlightGear without having to make any code-changes or the need to recompile the whole application - you usually provide a generic and simplified set of methods to extend an application, this allows also those users who are not that familiar with the internals of a project to make meaningful contributions.
This gets particularly interesting with functionality that's very specific and is not needed by every user - a functionality that might not even have the slightest chance to ever get accepted for an official release.
So, basically the whole plugin idea is about _dynamic_extensions_ !
Even *opensource* projects make use of support for dynamic extensions, either by really using plugins (i.e. loading binary libraries) - or more widely spread- by using a powerful scripting interface to allow execution of custom scripts within the application context.
The current way to make bigger -coding- contributions to FlightGear is to really dive into the sources and find the right place to integrate your stuff.
Also, there really seem to be already things integrated which seem to me rather SPECIAL - e.g. things like GPS data processing.
So, how many people (regular flightgear users) are ever going to make use of something like that ?
Don't get me wrong, I think it's _great_ to have a lot functionality integrated, but on the other hand there are certainly good ideas which to some of you appear as "beyond the scope" of FlightGear and which hence would not have the chance to be integrated into the "real" (official) FlightGear sources, even though they would appear useful to others - and I am not even speaking of my ideas here, which several FlightGear users/developers seem to like.
It's a solution to a problem that, honestly, we don't have yet. We aren't that big.
As you can see above the whole plugin idea is not really always about a project's "size", in this discussion it's rather mainly about enabling independent contributions - without the need for a programmer to directly modify the FlightGear source code itself.
If an idea can be added by the means of a scripting language *ALL THE BETTER*, but if it can't you'll have to get your fingers dirty and directly add the functionality to FlightGear using C++.
Now imagine someone like me ;-) starting to modify your precious FlightGear sources to add some weird functionality, probably also causing confusion thereby, as a new user would lack the familiarity with the FlightGear design/architecture...
The key feature to me is really _independence_, you can keep developing your plugin/module without the need to rely on (new) releases of the official project.
Of course, a powerful scripting language interface would also have exactly that advantage in most cases, as long as the interface isn't significantly changed in the actual release.
So, you see I am not necessarily recommending to add plugin support but rather provide a general way to provide dynamic extendability.
*Very* specific ideas would still require modificiations to FlightGear itself or rather its plugin/scripting interface - so I am certainly not about to recommend to make FlightGear the "swiss army knife" as mentioned by another poster here :-)
I think as you get used to the existing architecture, you will find that most of the "extensions" you are thinking of are best implemented as augmentations (or even rewrites) of pre-existing code instead of pluggable, not-quite-orthogonal extra features.
I do understand that argument, but then again I think you really need to take into account that there are certainly feature additions that are way too specific or simply not relevant to FlightGear itself, or at least the purpose it was designed for.
By providing a general method to easily extend FlightGear, be it via a plugin- or scripting-interface one would make sure that all these ideas could still be implemented WITH the *OPTION* to integrate that functionality into _EVERY_ offical FlightGear release as such features would no longer be merely integrated into custom modifications of FlightGear but would rather be available to EVERYBODY who's using FlightGear and hence the USER would _decide_ what's useful and what's not necessary.
So, it wouldn't be the FlightGear developers anymore who decide what's going to be integrated into FlightGear, but rather every user could integrate his/her own functionality - meaningful additions could still be easily added to the FlightGear sources itself.
-------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
