Re: [certi-dev] Java Binding

[Eric Noulard]

2010/2/28 Eric Noulard <address@hidden>:
> 2010/2/28 Andrej Pancik <address@hidden>:
>> 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.

Andrej,

I did try some evolution in the message generator (and the specifications) which
should enables you to do what you want.

I have added the notion of "combined" message field.
For example the UAV message specification is now:

message M_Update_Attribute_Values : merge Message {
         required ObjectClassHandle     objectClass
         required ObjectHandle          object
         combine AttributeHandleValuePairSet {
              repeated AttributeHandle       attributes
              repeated AttributeValue_t      values
        }
        optional EventRetractionHandle eventRetraction
}

as you can see the fields attributes and values are "combine" into
a AttributeHandleValuePairSet.

The combine type itself is a a native message:

native AttributeHandleValuePairSet {
    representation combine
    language CXX   [#include "RTItypes.hh"]
    language Java  [import hla.rti.SuppliedAttributes]
}

This means that now you know that those fields should be "combined"
by the generator backend into a to-be-matched native type.
However it also means that the message must  be serialized
as-if there were the "uncombined fields".

You can add as many "language Java  [xxx]" lines you want in order to be able
to do the match more easily.
Note that we will( must) be able to support several variant
(JavaHLA13, JavaIEEE1516, CXXHLA13, CXXIEEE1516)
variant using this scheme, while keeping the same "internal"
serialized messages.

I think the mechanism is powerful enough to cleanly implement your ideas
and keep as many informations as we need for serialization,
what do you think?

During this update I did split the monolitical GenerateMessage.py script into:

GenerateMessages.py - the main as before
GenMsgAST.py - the AST type definition and ASTChecker
GenMsgBase.py - the message generator base class including MsgSpec
GenMsgCXX.py - the C++ message generator  (updated to handle combine fields)
GenMsgJava.py - the Java message generator (not updated [yet])
GenMsgPython.py - the Python message generator

I did not have time to update your message generator
but I can give you a hand on this if you want.

Now at least we can work on GenMsg<LANG>.py in a clean separate fashion.

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