At Thursday 10:04 AM 7/25/2002, you wrote:
Oops, my last paragraph should have read:
Therefore I can't see any technical reason to NOT to create and maintain static header files for runtime (or at least compile & link) compatibility.

This certainly *can* be done, but does have a limit.  This only works for 1.3, not 1516, and can only be "effectively" kept the same for a platform, where a platform is defined as on OS/compiler combination.    This also does not mean it *should* be done.  The major item that triggered this conversation is the change of RTI from a class to a namespace, which does have its benefits.  Everyone seems to agree that RTI 1.3 will continue to be used for a while.  We are now at a point, many years after the original draft, where compilers support many new features, such as namespaces, which ease in development.  At what point do you take advantage of these features?  When you want to include such additional capabilities, how do you do it?  Do you declare a new version of the draft?  Answers to this depend on the intention of the specification.

Currently it is not spelled out anywhere what the exact compatibility between 1.3 RTIs should be.  Link compatibility has only become expected out of convention and experience.   The RTI-NG has never claimed to be plug-and-play between its own versions, let alone with Mak.  It simply has happened to work in the past.  One could argue, and quite credibly, that link compatibility is an addition to the specification.  Its certainly is not spelled out.  The header files are there in the April 98 draft, but they are now out of date and wrong.  Furthermore, nothing ensures that all RTI vendors will modify the header files to support additional platforms in the same way, which I think everyone agrees must be done.  By convention, vendors have simply followed the DMSO approved header files.

Whatever the requirement, it needs to be spelled out.  We can just say 1.3 is what it is and if you want to use newer C++ features, move to 1516.  Interestingly, 1516 puts to an end the day of link compatibility and this whole discussion is moot.  You can modify header files only to support new compilers and OS's.  To me that would doom RTI 1.3, and perhaps HLA, to obsolescence.  Another approach is to have a standards committee that maintains and versions the header files.  This at least allows for improvements and allows the RTI to grow with technology, as any middleware product needs to. 

It would be intersting to know what federate and RTI developers think on this issue, outside of the 4-5 people who have participated in this conversation.  Do folks need some kind of link compatibility?  If so, what about 1516?  Does anyone plan on using 1516?

I don't expect these questions will be answered here, but it would be intersting to know.

 As to what exactly the content of the header files should be or whether IEEE 1516 vs RTI 1.3 should win out, I'll leave that to the more knowledgable folks in this forum.

Randy Pitz
Software Engineer
Boeing Training Systems
[log in to unmask]

Keith Snively
Dynamic Animation Systems