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

To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: