Re: [certi-dev] Java Binding

[Eric Noulard]

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)

> 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.

OK.

> By the way I do not know any elegant way to determine what
> corresponding data interface to use when serializing and deserializing
> messages.

The rules should be easy, let's take an example:
message M_Reflect_Attribute_Values : merge Message {
        required ObjectClassHandle  objectClass
        required ObjectHandle       object
        repeated AttributeHandle    attributes
        repeated AttributeValue_t   values // FIXME check this one
        optional EventRetractionHandle eventRetraction
}

A) plain non-repeated "scalar" field
    like objectClass, object, eventRetraction

   A.1) if they do have "representation" like
   native AttributeHandle {
    representation uint32
    language CXX [#include "certi.hh"]
    language CXX [#define ATTRIBUTE_HANDLE_UNDEFINED_VALUE 0]
   }
   you do know how to serialize them (with eventual cast during read/write)
   I generate getter/setter pair for this kind of field e.g.:

    ObjectClassHandle objectClass;

   const ObjectClassHandle& getObjectClass() const {return objectClass;}
  void setObjectClass(const ObjectClassHandle& newObjectClass)
{objectClass=newObjectClass;}


  A.2) the same is true for field which have "basic" types:
uint8/16/32, double, float; string.

  A.3) if they correspond to native type without representation
  currently we cannot do anything beside hard-coding the solution in
the generator.
  In the current message specification there is "only" the Extent type
  used in DDM messages and this is not handled properly even in C++ :-(
  I'll tackle this as soon as we have a clean DDM test case.

B) Optional field
    When a field is optional I generate a boolean + the field itself e.g:

    EventRetractionHandle eventRetraction;
    bool hasEventRetraction;

    Then you have the same rule as for the A) with conditionnal serialization
    based on the value of hasXXX.
    The value of the boolean itself is ALWAYS transmitted has an uint8.

    NOTE: THERE IS NO "optional repeated" field keep reading.

C)  Repeated field
     A repeated field is a sequence of field of the same type thus
     we serialize it as:
        1) the sequence length serialized as an uint32
        2) the field values serialized with rules A).

    The sequence may be void but the sequence length is ALWAYS transmitted
    this is why we don't need "optional repeated".

    The getter/setter generated for the repeated fields are 6:

    uint32_t getAttributesSize() const {return attributes.size();}
    void setAttributesSize(uint32_t num) {attributes.resize(num);}
    const std::vector<AttributeHandle>& getAttributes() const {return
attributes;}
    const AttributeHandle& getAttributes(uint32_t rank) const {return
attributes[rank];}
    AttributeHandle& getAttributes(uint32_t rank) {return attributes[rank];}
    void setAttributes(const AttributeHandle& newAttributes, uint32_t
rank) {attributes[rank]=newAttributes;}

    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....

> 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.

OK you got a point.

> 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 "

OK in order to support what you want we should find a way
to describe how to serialize a native structure (like HandleValuePair)
for which representation may not be mapped to "simple datatype".

We may decide that such type should be something like:

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.

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?

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.

In current CERTI C++ code we do copy because the representation
in the message is not the same as the one in libRTI. It may be
change in CERTI C++ but we would have to make a choice
when going IEEE1516 for which we now have:
 typedef std::set< AttributeHandle > AttributeHandleSet;

and not a pure virtual class.

> 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:

AttributeHandle
ParameterHandle
ObjectHandle
ObjectClassHandle
DimensionHandle
etc...

all these type have "representation uint32"
(unless there is some typo remaining).

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.
-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org