Re: [certi-dev] Java Binding

[Eric Noulard]

2010/2/28 Andrej Pancik <address@hidden>:
> On Sun, Feb 28, 2010 at 7:49 PM, Eric Noulard <address@hidden> wrote:
>> 2010/2/28 Andrej Pancik <address@hidden>:
>>> Hello,
>>>
>>>  A lot of identifiers have changed therefore it is necessary to modify
>>> guts of Java libRTI.
>>
>> I know that and I'm concerned by the fact that those changes
>> make you somehow redo what you have already done.
>> However I find it essential in order to have a clean message specification
>> and I hope that when the Java generator is ready changing
>> content or name of a message may be done very fast.
>> (for any binding using the generator including Java)
>
> This will always bog when changing names of identifier since you have
> to change them also in rti ambassador code which is not generated. But
> it is not a problem I understand the importance of such effort and I
> will do that as soon as proper generation of classes is done.

OK, thank you for your understanding.

>>
>>    using this libRTI may be implemented easily with some
>>    hand-writtent helper functions used to convert from combined
>> attribute/values
>>    or parameter/value pairs to std::vector<AttributeHandle>
>>    std::vector<AttributeValue_t> etc....
>
>
> But that is the point. Helper functions should be called by generated
> code. But to call them we need to know to which structure we want to
> convert. This information is not supported by data right now.

I wasn't looking at that this way.
Currently in C++ code the helper functions are "manually" code
in the libRTI code.

The generator does not know anything about
the libRTI specific data structure but the generated code
should makes it easy to manually code libRTI.


>> native HandleValuePair {
>>        representation serialize
>>        language CXX [#include "certi.hh"]
>> }
>>
>> which would mean that there exist some "native"
>> void serialize(MessageBuffer& msgBuf, HandleValuePair hvp);
>> void deserialize(MessageBuffer& msgBuf, HandleValuePair& hvp);
>>
>> functions we can rely on.
>
>
> If we use this approach I can include conversion (by calling
> corresponding method) to complex type in de/serializefunction in
> generated code
> for example:
>
>  repeated AttributeHandle attributes
>
> can be automatically recognized by generator as
>
>  AttributeHandleSet attributes;
>
> and automatically transformed into proper de/serialization code.But
> only if there are HandleValuePairs as different entities (to make 1-1
> mapping).  I think that this is very convenient. Beta version of Java
> libRTI (and also the beta generator) is made that way. I can make more
> comments regarding this if needed.

Ah ok I did not catch that, this is a good idea.
I should try it in the C++ generator too, and I think I now
totally agree with the approach. I should give it a practical try
in order to be sure I'm not missing some caveats.

>> The other options would be to create a non native message type:
>>
>> message AttributeHandleValuePair {
>>    AttributeHandle handle
>>    AttributeValue   value
>> }
>>
>> (note that this message doesn't need to inherit from Message
>>  base class because it won't be sent on his own)
>>
>> then we can use
>>
>>     repeated AttributeHandleValuePair
>>
>> and generate the code accordingly.
>>
>> What would you prefer?
>
> I like the first approach with native types.

Ok noted.

>> Either way in the libRTI you'll have to map the HLA enforced type
>> (e.g. SuppliedAttributes) currently in the java implementation
>> you use the same representation thus you can cast.
>
>
> Not really. The point is that generator should know which type we want
> at the end e.g. SuppliedAttributes and generate code that handles
> aggregation from arrays to complex structures. Right now information
> obtained in generation data is not sufficient to determine which
> structure are we working with and combining arrays is up to programmer
> of rti ambassador.

OK agreed, but using this approach if we may have to use
different (internal) message type for HLA 1.3 and IEEE-1516
[because the types used for xxxSet changed from 1.3 to 1516]

>>> 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.
>>
>> Why do you say that?
>> Normally each attribute has its most precise type now:
>
> Sorry if I did not write that explicitly. I did not mean simple types
> but complex structures such as FederateHandleSet, SuppliedAttributes,
> ReflectedAttributes etcetera,

OK, understood now.

>> so the generator should really know what to do with that.
>> I did not begin the "modularisation" of the generator but I'll begin soon
>> I'll try  add your request for supporting "native" non-simple type
>> (at least at the generator syntax parsing level) during the work.
>
> My response is included up there in the body of your email. I will try to 
> write
> more verbose explanation of my point of view on this issue tomorrow if
> needed - please write if it is the case.

I think I caught your point.
I'll give this a try and keep you informed.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org