At Thursday 10:04 AM 7/25/2002, you wrote:
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.
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.
Boeing Training Systems
[log in to unmask]
Dynamic Animation Systems