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

[Eric Noulard]

2009/5/26 Gotthard, Petr <address@hidden>:
> Hi Martin,
>
>> Yup, I know about Portico, but adding the entire Portico RTI to the
>> game plus a CERTI bridge would make the entire thing a bit bloated and
>> a lot more complex. I suspect that our friendly primary author would
>> rather implement CERTI's wire protocol in Java himself than plugging
>> yet another beast into the queue.
>
> Implementing CERTI's wire protocol is one option, but such solution
> would not be interoperable with other RTI (like MAK). This may thus
> block commercial MAK RTI based applications from connecting to the
> simulation.

Agreed one should use "standard" Java HLA API.
Then the next question is "how to bring Java HLA API" usable with CERTI.

1) Implement Java HLA for CERTI
      1.a) do it natively within CERTI i.e. implement libHLA, libRTI,
RTIA, and the necessary part of libCERTI
              (RTIG may remains on its own because it is already
standalone and portable)
              In this case you'll talk the CERTI on-the-wire protocol
with RTIG (aka NetworkMessages).
              This is a lot of work because all RTIA must be re-written.

      1.b) do it natively within CERTI but only for libHLA and libRTI.
Since Federate speak
              to RTIA through a socket one may use the C++ RTIA with a
java libRTI.
              This was the way taken by our students:
                  https://savannah.nongnu.org/task/index.php?6905
              In this case you'll talk the CERTI on-the-wire protocol
with RTIA (aka Messages).
              This is less work than 1.a since you "only" need to
implement Message with RTIA.
              I'll add comment on the tracker on this choice.

2) Implement some bridge with other RTI which do already provided Java HLA API.
     This was my proposal for Portico/CERTI bridge.

> Another option would be to implement a bridge between the standard Java
> HLA API and the standard C++ HLA API provided by CERTI. I'm not a Java
> expert so I cannot assess the technical consequences, but from user
> perspective it's better: It does not plug another beast and it may have
> a wider audience as it would support all standard compliant RTI. CERTI
> is a nice piece of software, but sometimes it cannot be used.

          Looks like option 1.b) ?


-- 
Erk