Re: [certi-dev] Request for comments: Python bindings for HLA

[Eric Noulard]

2008/8/19 Gotthard, Petr <address@hidden>:
> Dear all,
> I would be very interested to hear your opinion about (hypothetic) Python
> language bindings for HLA. The point is that the Python language would
> facilitate a very high-level language mapping for HLA that
> could significantly simplify the model development.

Hi Petr,

I very seduced by the idea of a Python binding, for just the same
reason you are evoking, it will greatly improve productivity and ease of use.

> Attached document illustrates the ideas so far. Comment of any kind are
> welcome, but I'm most interested to discuss the features of the (hypothetic)
> Python language extension.
>  - What HLA features must be exposed by the Python mapping, i.e. what may be
> automated?

I think Python mapping should expose may be a 2-level API.
A first one which should stick in a both object-oriented and pythonic way
to HLA / IEEE1516, FederateAmbassador API and RTIambassador API.
Using this API one can write a python Federate with known HLA words

For example the fist level would be::
# create an RTIambassador object
myfed[rtia] = hla.RTIambassadorFactory.create("federate")

# create federation execution
myfed[fedex] = rtia.createFederationExecution("federation","model.fed")

# create a (Null)  FederateAmbassador object
myfed[fedamb] = hla.FederateAmbassadorFactory.create()

myfed[rtia].joinFederationExecution()

Then the second level will gives non-normalized simplier API

mySimpleFed = 
hla.simple.createAndJoinFederate("federate","federation","model.fed")

hlaDataTypeHelper  = hla.simple.use("rpr-fom.xml")

aircraft = hlaDataTypeHelper.Aircraft()
mySimpleFed.publish(aircraft)
....

I like the two-level API because design a "clean" simple API from the ground-up
would probably not be done in a single pass, thus once the "basis" API is done
one can concentrate on the upper-level (with may be several approaches).

I think you should keep 1 federate == 1 object because this way you can
be close to an "active object" paradigm.
Active object is a "programming paradigm" that was used in different languages
a lively example being ProActive Java:
http://proactive.inria.fr/release-doc/html/ProActiveBasis.html

>  - What Python features may be best used to implement the mappings?

If you want to address many RTI from the ground-up may be using Python/C++ API
and/or SWIG (http://www.swig.org/) will do the jobs.
I don't like the approach because:
   - you loose python portability
   - you'll [probably] need a specific python extension for each RTI
(and each platform) anyway

If you target CERTI in the first place then you may implement a 100%
python binding
because you may implement a python libRTI using CERTI message encoding written
directly in python. There is work but one may generate almost all python code
for building CERTI message. Moreover the CERTI RTIA may use a TCP socket
(and not Unix one) if launched with "-p" option which specify a TCP port.
This way one may use rtia and rtig binaries with a 100% python
(java/ruby/whatever...)
libRTI.

I think the first approach is a must go in order to have a wide audience
the second one would really be interesting for CERTI user.

Regarding "Pythonic aspect" I would say that I would stick
object-oriented python
as much as possible and try not to use "binary" python extension but
only pure-python ones.
I would use as much dynamicity as python offers and measure performance
penalty on selected example in order to control the performance
penalty of the dynamicity.
I think python dynamicity won't be a performance killer unless it is
heavily used
inside the simulation loop.

> I hope I haven't reinvented the wheel. Please stop me if I have.

I personnally don't thin so. This is an interesting idea.

As a side note I crossed another "high-level" HLA tool reference
(I have not tried the product though) :
http://www.calytrix.com/siteContent/SIMplicity/intro.php

-- 
Erk