Boris Koenig wrote:
By the way, the addition of a plugin architecture has pushed all major flight simulators tremendously forward, I don't even mention stuff like Microsoft's FS, but I suggest to have a look at X-Plane: Since the author added support for basic plugins, there are numerous projects to interface with X-Plane, some of them concentrating on multiplayer stuff - others on specific things like integrated preflight-support.
By saying this you imply to be looking at FlightGear in a much too commercial way.
Sorry, you are definitely wrong, besides: there are not only commerical "AddOns" to X-Plane. I really don't have any commercial intentions.
If the source is open there is little need for a plugin system.
Well, I've heard that argument several times now - and of course you are right in saying that one COULD directly modify the FlightGear source code in order to incorporate some desired functionality.
But do you really want to have to change the whole FlightGear code for some specific functionality ?
To get back to the "swiss army knife"-example: I do think that example becomes legitimate when it comes to very specific requirements or ideas, the only alternative that remains then would be to create a branch of the original FlightGear source in order to add some specific functionality-something I would personally never consider...
This is another point: How about people who have suggestions (possibly even a bit extraordinary) but who like these features to be OPTIONALLY being available in all FlightGear versions ?
Speaking of myself now: while I pondered about the pros & cons for a FlightGear enhancement such as the "FliteTutor" concept, I would have really love to be able to do this via some kind of plugin structure.
This also for the very same reason that we can currently watch here: people feel differently about certain features, "enhancements" or suggestions.
And I do understand this quite well.
Let's consider the FliteTutor example again: IF I really start the first coding attempts,I will very likely have to add some commands to Nasal - and I really wouldn't hesitate to do this directly into FlightGear's source, BUT what we have then is ONE modified version with, that some people might still object against to integrate into the real branch.
Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project.
I don't think that would be a major problem, there's other opensource
(GPL'ed) software that makes use of modular enhancements (aka
"plugins")- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a
module needs to provide the licence under which it is available in
order to be loaded (This is a kernel 2.65 addition I think).
Now you could argue that you will be opening up the source of the plugin, but I'm not so sure about others.
Okay, that's a point - a point that hasn't yet been made. Personally, I really wouldn't have any problems about releasing any sources - except maybe, because of their lack of elegance ;-)
But I think one could really find a solution for that problem, e.g. either by really making a plugin provide the licence under which it is available - and deny those plugins access, which do not specify an acceptable opensource licence OR by selectively maintaining an internal list (within FlightGear) of plugins that FlightGear would load (because they are opensourced).
---------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
