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

[Gotthard, Petr]

Thanks Eric,
I knew you have good ideas. I will update the proposal accordingly.

One comment:
If I use a 100% Python implementation, I lose the RTI portability. For
me the RTI portability is much more important than the Python
portability, because I need compatibility with MAK RTI based products. I
see the benefit of developing the "high-level" API in 100% Python, but
some issues (e.g. the 1516.2 value encoding) may be more easily solved
in C. [This may be also because I'm much better C/C++ developer than a
Python developer.]


Petr

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Eric Noulard
Sent: Wednesday, August 20, 2008 9:32 AM
To: CERTI development discussions
Subject: Re: [certi-dev] Request for comments: Python bindings for HLA

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


-- 
CERTI-Devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/certi-devel