certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gotthard, Petr
Subject: RE: [certi-dev] FlightGear FOM / Java interface
Date: Tue, 26 May 2009 10:50:37 +0200

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.


Petr

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Eric Noulard
Sent: Tuesday, May 26, 2009 8:10 AM
To: CERTI development discussions
Subject: Re: [certi-dev] FlightGear FOM

2009/5/25 Martin Spott <address@hidden>:

>
>> Would  a Portico/CERTI bridge be enough? (see http://www.porticoproject.org/)
>> Or do you really need "native" CERTI in Java?
>
> 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.

I understand that very well,
the fact is maintaining another binding is time consuming.
However if someone wants to give it a try we will definitely help her/him
to do it with pleasure.

The person will need to acquire some basic knowledge of HLA
(including standard Java API) and part of the internal CERTI internal
messaging.

That's what our student did began to do.


2009/5/26 Martin Spott <address@hidden>:
> Martin Spott wrote:
>
>> The primary author is a little bit 'insisting' about "doing things
>> right"  :-)  Thus, having a pure Java abstraction layer to CERTI [...]
>
> BTW, as I understand there is a HLA 'standard' API for Java which is in
> most parts supposed to resemble the various implementations by Portico,
> Pitch, OHLA and others (maybe Mak as well).
> Even though having a standards-compilant Java API available for CERTI
> would certainly be best, it probably might not be an absolute
> requirement for adding CERTI/HLA support to the OpenRadar ....  as long
> as the API doesn't change too often  :-)

Yes agreed, in fact we need to target the standard Java API from the beginning
and this won't change (at least not until HLA is revised). However it may
be possible to only implement the needed part of the API and let some part
"unimplemented".


-- 
Erk


-- 
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]