On Nov 30, 2005, at 4:46 PM, David Luff wrote:
Joacim Persson writes:
I'm curious about the choice of language/linkage for the
implementation:
Why have a specific vendor model hard-coded in c++? Seems more
like task
for xml/nasal scripts to me. ?:-P Nothing wrong with the language
(c++)
but isn't it a little out of place in the fgfs /core/.
That's a fair point. I used c++ because that's what I'm used to,
and that's what I *know* can get the job done without running into
major obstacles, whereas nasal, and adding the 'C' code function
hooks for it, is an unknown quantity to me. Additionally, the c++
code could concievably be used as the basis for a standalone KLN
unit simulation where nasal is not available, for instance as an X-
Plane or MSFS plugin. Not on my TODO list, I hasten to add!
Another way to go (in the future) could be implementing specific
instrument
models as "plug-ins" -- dynamic objects. Then the model designer
can choose
implementation language freely. (If for instance one is well
familiar with
c++ and find nasal et.al. awkward to work with.) It could also be
easier to debug in that manner. (using stubs)
I agree, a plugin architecture would be ideal, since then complex
avionics UIs wouldn't have to add weight to the core code in terms
of compilation time, compiled code size and so forth. However, a
plugin architecture would have to be well thought out, and
crucially, stable, to avoid plugins that by definition aren't
compiled by all developers having the interface shift from beneath
them.
I have no experience of plugin architectures, and don't feel
competent to attempt it at the moment. I'd happily alter the kln89
code to make use of one if available though.
There is another issue to keep in mind for a plugin architecture
which is the different platforms that FG runs on. At the moment FG
probably runs on what?... maybea dozen different architectures
(Hardware/OS type/Version combinations)? Each plugin would have to
be built for each one? By having the code the the main part of FG
then each build will include testing and fixing. However if people
each develop a plugin that only works on their personal development
machine it will complicate things. And many of the common
architectures handle dynamic objects differently.
Then would we have a whole matrix on the web site of plug in X,
version Y is available for Platform Z, but will only work with FG
version Q? Pick and choose, download and see what happens. If each
person who does a build has to build all of the plug-ins at the same
time, then they might as well just be included in the FG source code,
and statically link.
I am not saying that it can't be done, but there are some issue to
work out. Essentially plugins would be separate mini-projects that
each would have the same issues as FG itself.
--Adam
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
