abassign wrote in Wed Dec 30, 2015 11:47 pm:@Curt
what you described is the problem of so many others. I tried to define a slightly different approach that allows to separate completely the main-loop Fgfs with the loop managed by Python (or another language). This way you can have something more solid, an execution environment completely asynchronously to the main-loop, controlled by events that the main-loop send. Will then loop Python to respond to these events in the most appropriate according to the written program.
I think it's important to come off from the couple XML-NASAL, which proved difficult to manage for large projects, such as SU15 or F15 etc ... With the structure that I propose to allow programmer to do what he wants, but at the same time to respect the current environment and at the same time give a real meaning to the hard work HLA/RTI, which makes sense only if made usable by anyone.
De facto connection framework replaces XML calls to functions written in a certain language. Are there not many XML structures that are transcribed through the connection framework and I feel that the current XML interfaces with C++ equivalent structures featured in the main-program.
Certainly ask those who know the core of Fgfs a series of calls to replace the XML interface can seem like an insane .. But in reality we are only asking to move the load of certain activities at the edge.
I would then come to favor the development of aircraft or objects that can respect different models of intellectual property and should not be rewritten every time changes the structure of FGFS.
A good-Connection Framework simple and light can remain very stable over time and grow in functions that do not affect the previous versions.
Let's see how the Conservative Party, currently in power, responds to my proposal, I'm curious;) and I also hope that it can avoid continuing its offensive manner of analyzing the problem.
Don't be mistaken here: Curt is the "leader" of the conversative party, so to speak: He explicitly suggested to think in terms of an optional feature, with optional dependencies - i.e. a custom build mode that could be enabled during build time. I briefly mentioned how this could be done. Curt explained also that Nasal had to stay for the time to come.
What you keep doing here, probably without realizing it, is that you are disqualifying yourself from being taken seriously due to the nature of your postings, either because they're ill-informed or too abstract, lacking in detail and missing any relevant context.
Thorsten asked for facts and for evidence - I also stated that those would be hard to bring up in this context.
However, in terms of "facts", the only thing that truly counts is the existing code base, but also existing functionality.
Don't expect to revamp either the source code, or any functionality, without also taking the other into account.
Obviously, all contributors have a certain "vision" for FlightGear, i.e. something that "motivates" them to contribute (to varying degrees), however that vision must somehow align with the facts, i.e. existing features and existing code.
Some people have a remarkable track record of working with FlightGear doing unprecedented things - however, FlightGear has become a massive project, and there is not a single person intimately familiar with all parts/aspects of it and its evolving ecosystem, and sometimes people's involvement dates back to a long time ago, so that their statements may have become inaccurate over time - but at the end of the day, there are "veterans" involved in the project for over a decade, i.e. people who literally spent 10+ years contributing to the projects in various areas, while many have only touched a few parts, others have embarked on large-scale architectural changes (think Mathias Frohlich, James Turner, Timothy Moore) - so their opinions and statements are based on facts, i.e. on working with the code and features that you want to change.
There is a general consensus among all active core developers that the want to split up the simulator using HLA, and that is not because HLA is such a great thing, but because using HLA allows to address a handful of issues at the same time, i.e. allowing things like the fdm/autopilot or scripting to run in their own threads/processes, split off rendering from simulation loop, but also distribute FlightGear in general - so that most subsystems can become standalone processes that only use IPC/RPC to communicate with other parts of the simulation. At the end of the day, HLA may not be the only option to accomplish that (FG already has support for various IPC mechanisms, many custom ones), but HLA is an important standard, especially when looking at the simulation industry, so it will also allow interoperability with other simulators, while allowing a plethora of long-standing FG issues to be tackled at the same time, such as modernizing the multiplayer system, factoring out the AI traffic component, unifying AI traffic and MP - but also providing support for multi-instance setups, like those at FSWeekend/LinuxTag.
All this is makes the HLA pathway extremely compelling, because there is a single IPC mechanism that can help with all of this and more, without having to juggle a handful of different IPC mechanisms or technology stacks (think CORBA).
So even if you don't agree with everything that's been said here, you should give people the benefit of the doubt, given their involvement in the project for so many years.
None of that is to say that Python support could not also be a huge technology enabler for the FlightGear project, but you are currently doing a disservice to the idea by the way you are posting, and by your way of tossing with abstract ideas without looking at the facts, and ongoing trends/developments.
HLA may not seem relevant/applicable to you, or even bugman, but that is mainly because of your background and the use-cases you have in mind, once you look at the bigger picture, you will inevitably have to reinvent an IPC mechanism like CORBA/HLA to accomplish what you want do.
For the time being, I think you are doing a disservice to your desire to have Python support in FlightGear, while also disqualifying yourself from receiving the very help that you obviously need so urgently (I honestly doubt that even bugman is going to put up with you now ...)
At the end of the day, what I think, say or do doesn't matter at all - so you could just as well take your fancy ideas and implement them (well, try to), but I doubt it will take you far given what I have read so far.