Re: [certi-dev] FlightGear FOM / Java interface

[Eric Noulard]

2009/5/26 Gotthard, Petr <address@hidden>:
> Hi Eric,
>
> After reading your e-mail I think your solution may be better that those I 
> described in my previous mail. The MAK RTI seems to also have a Java binding, 
> so what you suggested is reasonable.

I think our idea are pretty much the same.
May be you thought of using JNI for calling C++ shared lib from Java?
If that's the case I'd rather not go this way because JNI is not
bringing us much of portability.
I bet we need special case for each plaftform we want to support.
Moreover I experienced weird memory leak from within JNI which needs explicit
memory release, not a big deal but this wasn't an interesting problem :-)

In fact the idea to chose the frontier between binding at the socket level,

either Federate<->RTIA
or RTIA<->RTIG

will really ease portability. We "only" have to describe the CERTI
Message protocol
(either NetworkMessage or Message) and we may even generated the code
for handling marshalling/unmarshalling of thoses messages in the appropriate
language (Java, Python :-), etc...) using those if we decide
to go at "Message" level we "only" need to implement libRTI.

The benefits would even be to ease the realisation of inter RTI bridge because
the bridge may be implement using the CERTI Message protocol too :-)

The "only" drawback with this was that on Unix we use UNIX socket between
Federate and RTIA, but I did add the possibility to ask RTIA to use TCP instead
(just as we do on Windows which lacks Unix socket).
This is currently a compile-time option  see RTIA_USE_TCP CMake option
in certi/CMakeLists.txt.


-- 
Erk