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

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 data

That 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

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

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

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

So, you see I am not necessarily recommending to add plugin
support but rather provide a general way to provide dynamic

*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

Reply via email to