Sent From: [log in to unmask]


> We shouldn`t see content in the RTI headers flopping back >and forth, and users should be able to switch between RTI implementations >without modifying their code. Please note that with 1516 header files, simply replacing DLLs will not necessarily be possible anymore. The header files are set up to allow differing RTI implementations to put things in the header files that make them more efficient for users with a given RTI, without making users change any code. And these header files can change between releases of a particular RTI, again in such a way that users do not need to change code, but will need to recompile (how many of you actually just drop in libraries when you get a new RTI anyway, most people recompile to be safe?). On the other hand while users do not need to change any code, they will most likely need to recompile their federates to move from one implementation of a 1516 RTI to another. This is simply a fact of the way the header files are set up. Now, one implementation can make their version link time compatible with another, it seems that may give up the possibility of providing RTI implementation specific optimizations for the chance to be link compatible with another version. -frank >Steve > >-----Original Message----- >From: Len Granowetter [mailto:[log in to unmask]] >Sent: Monday, July 22, 2002 5:48 PM >To: SISO - Run-Time Infrastructure and Communications Forum >Subject: Re: HLA Header Files are not ``Set in Stone`` (Was: Creating and >Destroying Federations) > > > >Just to set the record straight on the ``protesting`` of RTI header files >changes: > >The main reason that we (MAK) protested the namespace change to the RTI >API was not because we are RTI developers, but because we are RTI >*users*. We didn`t want to have to incur the cost of building, testing, >and release-engineering nearly 28 new product distributions (VR-Link, >Stealth, Logger, Gateway, VR-Forces, and PVD times 4 platforms each, and >yes, the MAK RTI too on its 4 platforms in order to maintain >link-compatibility with DMSO) just so that we and our customers could >use our products with DMSO RTI v5 and take advantage of its >improvements. Especially when that cost would have been so easily >avoidable. We also didn`t want to have to tell our customers that >*they* had to incur the cost of moving to a new version of VR-Link, >VR-Forces, etc., and potentially rebuilding, testing and >release-engineering themselves, just to upgrade to DMSO RTI v5. > >The cost is avoidable, because if the headers files don`t change from >release to release, end-users can just switch to the new RTI DLLs >without recompiling, just like you can upgrade your graphics driver >without recompiling your PC games. With the namespace change having >been backed-out, hopefully those who were still on v4 can easily upgrade >to v6 in this manner. > >By the way, I agree with those that prefer namespaces to nesting >everything in an ``RTI`` class. Namespaces are more technically elegant, >and were meant to solve exactly the problem that the Spec. developers >faced, whereas nested classes were not, really. But the important >question to ask is whether that little bit of extra elegance (with no >gain in functionality, by the way) is worth the cost to the industry as >a whole of making all HLA tool vendors and simulation providers rebuild >and release their federates in order to upgrade. To me, the answer in >this case is a clear no. > >By contrast, there have been other cases where I think changes *are* >worth the cost, and in those cases, I have argued the other side of >this. One case is the tick() example that someone brought up earlier. >Without tick() (or some similar mechanism like the one chosen for 1516), >the HLA Spec is only implementable by levying a very costly requirement >on federate developers: that they be able to handle RTI callbacks >asynchronously (in a separate thread). The benefits of amending the >Spec to include tick() in the API clearly outweighed the costs of making >the change (especially since at the time the change was made, I don`t >think anyone had yet implemented a tick-less RTI anyway). > > -Len >``Drake, Steven R`` wrote: > > > > Thanks for the information, Keith. I felt fairly confident that DMSO was > > approving these changes, but wasn`t sure how. Given the rather slow > > adoption of 1516 RTI implementations, I think the 1.3 specification will >be > > around for quite a while. I hope DMSO will take the time to update the > > specification to reflect changes that they approve. Furthermore, I hope > > that they`ll approve changes through some type of public process, and that > > loud protests from RTI developers won`t be necessary, nor honored... :-) > > > > BTW, I want to vote for namespace RTI rather than class RTI. Where do I > > send my ballot? > > > > Steve > > > > -----Original Message----- > > From: Keith Snively [mailto:[log in to unmask]] > > Sent: Monday, July 22, 2002 12:52 PM > > To: SISO - Run-Time Infrastructure and Communications Forum > > Subject: Re: HLA Header Files are not ``Set in Stone`` (Was: Creating and > > Destr oying Federations) > > > > The changes you state were made, along with another which was removed a >lot > > of ``define ...`` statements, which specified limits for things like the > > number of attributes allowed for a call to update. However, these changes > > had specific reasons and had to be approved by DMSO. The change I > > mentioned along with number 3 you list below presented real problems to > > federate developers. Without RTI_USES_STD_FSTREAM federate developers > > would always wind up with the pre C++ `98 iostream implementation > > (iostream.h instead of iostream). The defines I mentioned were specific >to > > an early RTI implementation and were never used by RTI-NG, and hence set > > arbitrary and misleading limits. > > > > The change you mention in number 1) facilitates a more straight forward >and > > more intuitive mechanism of printing exceptions. If you catch and > > exception as a const reference, which is generally recommended, it is more > > intuitive to print it using: > > > > cout << ex << endl; > > > > as opposed to: > > > > cout << &ex << endl; > > > > Furthermore, depending if you set up your include statements right, the > > second statement may just print out the address of the exception, which > > tends not to be very helpful. The first statement would simply fail to > > compile in that instance, which is better than trying to catch the error >at > > run-time. > > > > The final change you mention, changing RTI to a namespace from a class, is > > a good example of just how hard it can be to change the header files. The > > rational for the change was simply that RTI is used like a namespace ... > > not a class. You do not instantiate an object of type RTI and by making >it > > a namespace, classes contained in it, such as RTI::Exception, can be > > forward declared. This change also does not present any problems with > > compile-time compatibility with older implementations. RTI was originally > > a class simply because not all compilers would support a namespace, namely > > Sun SPRO4.2, which was widely used at the time. > > > > However, this change was protested by other RTI developers, and as a > > result, has been forced back to being a class. Certainly, any RTI > > implementation which attempted to add methods to RTIambassador which draw > > equally strong protests. Run-time link compatibility seems to be required > > for RTI 1.3 implementations, and new methods would certainly break that. > > > > The header files may not be set in stone, but they are in some fairly well > > dried concrete. ; ) > > > > Keith > > > > At Saturday 02:47 PM 7/20/2002, you wrote: > > >Nathan, and the rest, > > > > > >In working with RTI developers, I was also left with the impression that > > the > > >HLA header files were ``set in stone``. In fact some of the RTI developers > > >that I have worked with were forced to use some rather unconventional > > >constructs in their code rather than modify the DMSO-supplied C++ >headers. > > >I was told that this was because ``DMSO required it for certification``. >At > > >any rate, this does not appear to be the case now. Three cases come to > > >mind: > > > > > > 1) A streaming operator, that takes a reference to an exception > > >(rather than a pointer to an exception), has been added to the DMSO RTI > > > 2) RTI was changed from a class to a namespace in the DMSO RTI. > > > 3) A define for RTI_USES_STD_FSTREAM was added to the DMSO RTI > > > > > >None of these changes are reflected in the 1.3 spec at: > > > >https://www.dmso.mil/public/library/projects/hla/specifications/c_api_annex > > . > > >pdf > > > > > >Although I think these are positive changes to the interface, they *have* > > >required us to modify code to ensure portability between RTI > > >implementations, and indicate that there is a process in place to modify > > the > > >headers (albeit unknown to me). > > > > > >Steve > > > > > >Steven R. Drake, Software Engineer > > >Modeling & Simulation Technology, Phantom Works > > >Office: (256) 461-5771 Fax: (256) 461-2983 > > > > > >The Boeing Company > > >499 Boeing Blvd. MC JR-80 > > >P.O. Box 240002 > > >Huntsville, AL 35824-6402 > > > > > >-----Original Message----- > > >From: Keith Snively [mailto:[log in to unmask]] > > >Sent: Friday, July 19, 2002 3:28 PM > > >To: SISO - Run-Time Infrastructure and Communications Forum > > >Subject: Re: Creating and Destroying Federations > > > > > > > > >At Friday 04:16 PM 7/19/2002, you wrote: > > > > > > >``Barclay, Nathan`` wrote: > > > > > > > > >These header files are unfortunately set in stone, rather than simply > > >requiring compile-time compatibility. > > > > > >Keith Snively > > >Dynamic Animation Systems > > >http://www.d-a-s.com > > >SAIC:(703)333-5432, > > >DAS:(703)503-0500 > > >FAX:(703)425-2204 > > > > Keith Snively > > Dynamic Animation Systems > > http://www.d-a-s.com > > SAIC:(703)333-5432, > > DAS:(703)503-0500 > > FAX:(703)425-2204 > >-- >---------- > \ / . . / Len Granowetter > \/ _ ( MAK Technologies > /-\ \ (617) 876-8085 Ext. 121 > T E C H N O L O G I E S [log in to unmask] ----------------------------------------------------------------------- Frank Hodum voice: 703-333-5437 SAIC fax: 703-354-5227 5400 Shawnee Rd cell: 703-371-4925 Suite 110 [log in to unmask] Alexandria, VA 22312 email:[log in to unmask] -----------------------------------------------------------------------



To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=Z-ARCHIVE-SIW-CFI