Sent From: [log in to unmask]

The arguments on both sides of this question are cogent. However, through all of this, I`d like to determine what methodology is in place to support modifications to the 1.3 ``standard``. Although SISO has a hand in defining standards, the mantle for RTI-compliance testing belongs to DMSO...hence, they end up the defacto keeper of the standard. My gut tells me that they`re keeping their heads low and hoping the industry moves rapidly to 1516. I`m not sure that will happen, but I`m optimistically pessimistic on this one. If DMSO approves modifications to the headers, and it appears that they have, the ``standard`` needs to be updated, and the community needs to be informed. 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. Steve Monson has suggested that SISO take a larger role in this problem; I applaud that thought. 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: > > > . > >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 > > > >SAIC:(703)333-5432, > >DAS:(703)503-0500 > >FAX:(703)425-2204 > > Keith Snively > Dynamic Animation Systems > > 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]

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