Re: [certi-dev] Java Binding

[Andrej Pancik]

Hello,

 A lot of identifiers have changed therefore it is necessary to modify
guts of Java libRTI. My estimation is that I need few hours to get new
compatible Java generator to work, however since I had only a brief
look I did not fully assess the problem.

 By the way I do not know any elegant way to determine what
corresponding data interface to use when serializing and deserializing
messages. From my point of view it is easier to decompose
AttributeHandleValuePairSet to r/w of arrays of handles and values
than to compose r/w of both arrays to AttributeHandleValuePairSet
while crawling through message definition file in linear fashion.
Since I need to provide AttributeHandleValuePairSet to libRTI I have
to convert the data explicitly somewhere anyway. It would be much
better if it was done on generator part.

Just to be clear I am not opposed to "repeated" keyword. It has it's
important semantics. I just think that:

"repeated HandleValuePair reflectedAttributes"

is more appropriate to describe data strucuture than

"repeated AttributeHandle    attributes
repeated AttributeValue_t   values "

because "repeated AttributeHandle attributes" itself can correspond to
several SISO types and right now it is hard to determine in generator
which SISO type it should be mapped to.

regards

Andrej Pancik

On Sat, Feb 27, 2010 at 6:08 PM, Eric Noulard <address@hidden> wrote:
> Hi Andrej,
>
> As you may have noticed I finally reached the point were we can
> totally rely on CERTI_Message.msg specification for RTIA<-->Federate messages.
>
> Could you tell me if you did work on the Java generator backend?
>
> We may work together on this in order to makes it easier your work.
> There is now many difference on the message spec' you generated
> and the message spec I did check-in, mostly because I did prune
> some messages that were conveying too much information.
>
> We currently have one discrepancy regarding the Attributes/Parameters
> sequences in the CERTI messages. I did use sequence and not directly
> the RTI provided interface "AttributeHandleSet", "AttributeHandleValuePairSet"
> etc...
>
> I did wrote some conversion functions from the RTI interface to CERTI
> internal interface. I did this mostly because since we plan to support 1516
> we would have to do conversion anyway because 1516 defines other types
> for the very same items. So if we won't to support a multi-standard RTIA/RTIG
> we better separate the RTI specific types from CERTI internal types.
>
> Try to evaluate if this generates a "big" change for you and if you do
> not have time to go for it I may try to help you with that.
>
> Whatever is your answer I did tag in order to clearly identify the 
> compatibility
> breakage in the CERTI CVS tree.
>
> I will now work on some pending patches and go back to enhance
> the CERTI message generator in order to at least modularize the language
> generator backend in such a way that we can write a single file for each
> language generator backend.
>
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
>
> --
> CERTI-Devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/certi-devel
>