certi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [certi-dev] CERTI dev status and libHLA proposal


From: Gotthard, Petr
Subject: RE: [certi-dev] CERTI dev status and libHLA proposal
Date: Tue, 8 Jul 2008 11:20:15 +0200

Hi Eric,

I like your propsal. Both HLA specifications (HLA 1.3 and IEEE1516)
leave some issues open (e.g. value encoding), so a "helper" library
would certainly be very useful.


Petr

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Eric Noulard
Sent: Monday, July 07, 2008 5:48 PM
To: CERTI development discussions
Subject: [certi-dev] CERTI dev status and libHLA proposal

Hi All,

Now that CERTI 3.3.0 is behind us let's open the next step.
We would like to go forward differents pathes:

   1) full HLA 1.3 compliance
         * We lack MOM support
               https://savannah.nongnu.org/task/?6908
               No-one started this yet
         * We lack some Switch and notif
               https://savannah.nongnu.org/task/?6893
               Christian began the work on this.

   2) Prepare IEEE-1516 support
          Petr already provided some patch for IEEE-1516 type encoding
          https://savannah.nongnu.org/patch/?6534

   3) Provide tools for simulation analysis and performance enhancing
(log, performance, etc...)
         Nothing done yet.

Do not hesitate to browse the different trackers (bug, patch, tasks) and
propose patches for unassigned items and or propose review or
comment/ideas for ongoing work.

I'd like to propose something.
The IEEE-1516 type encoding proposal from Petr is independent from the
RTI (be it CERTI or other), some classes currently in CERTI are "helper"
classes which are autonomous too (*Clock, MessageBuffer)

I'd like to create a portable "libHLA" library which may be used by any
federate which may contains RTI-agnostics tools which are useful to any
Federate.

The class would be putted in a libhla:: C++ namespace, the libhla would
be built and distributed with CERTI for convenience but may be built and
used independently.

What are you (all certi-devel subscribers) thinking about this?

Your ideas are welcomed on the list or on the task I've just opened:
https://savannah.nongnu.org/task/index.php?8386
--
Erk


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]