20,741
edits
Nasal HLA standalone: Difference between revisions
Jump to navigation
Jump to search
m
→Hight Level Architecture
| Line 22: | Line 22: | ||
At some point, the ongoing HLA work should facilitate a scripting API exposed via HLA, so that scripting languages like Nasal (or Python or any other language) would be able to call FG APIs (like extension functions) via HLA | At some point, the ongoing HLA work should facilitate a scripting API exposed via HLA, so that scripting languages like Nasal (or Python or any other language) would be able to call FG APIs (like extension functions) via HLA | ||
Also, there's a standalone interpreter for unit testing: https://gitorious.org/~hooray/fg/hoorays-simgear/commits/nasal-unit-testing | |||
So we already do have a standalone Nasal interpreter that cannot currently talk to the fgfs process - making it talk to fgfs through HLA would be a first step, and the setprop/getprop APIs (or whole props module eventually) would be an obvious candidate, because the property tree infrastructure is already in place im simgear/hla (see HLAPropertyDataElement). | |||
One of the goals could be to support multiple standalone Nasal processes which run setprop()/getprop(), which in turn is marshalled through HLA/OpenRTI to fgfs. That would not seem overly complicated, but like a pretty simple and useful first use-case to allow people to run certain stuff outside the main process | |||
Obviously, one would need to expose other FG/Nasal APIs eventually, but we should probably learn to walk before we run | |||
{{cquote|Another thing that would work well is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts | {{cquote|Another thing that would work well is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts | ||