Proposal: Make RTPS the default
The PR for this work can be found here: https://github.com/objectcomputing/OpenDDS/pull/2454
The basic goal of making RTPS the default for discovery and transport was relatively easy. On the branch running the run_test.pl of DevGuide Messenger without any arguments will run using RTPS without any discovery or transport configuration.
Dealing with everything in OpenDDS that assumed otherwise wasn’t and still isn’t going to be trivial. Many tests and examples that assumed Info Repo, but didn’t need it were stripped of it or made optional, like DevGuide Messenger. Others that needed InfoRepo like MultiRepo test where changed to enable it. Both of these tasks are still probably incomplete. Others like the Messenger test will need to be reorganized around the fact that RTPS is the default, but it will need to test InfoRepo as well for some test cases. As part of this consideration should be made for the convention of config file names. Right now a config file name with a transport name is assumed to run InfoRepo, for example tcp.ini would be TCP transport with InfoRepo discovery. I think it’d be confusing to continue with this convention. Should we switch the convention (Example: tcp.ini/ir_disc_tcp.ini) or require the discovery name as part of the config file naming (Example: rtps_disc_tcp.ini/ir_disc_tcp.ini) ? Personally I’d perfer the later, as being more explicit reduces or eliminates ambiguity.
On the branch there is an experiment that was left half finished. InfoRepo was excluded from the build and some tests failed because of it. These tests need to be evaluated to see if they really need InfoRepo. If they do, then !NO_INFO_REPO should be added to their test entry. In the future we could have a CI or scoreboard build that uses NO_INFO_REPO and an option exclusion of InfoRepo to help enforce the isolation of InfoRepo.
Finally long term there should probably be some juggling of dcpsexe and StaticIncludes.h because of these changes. Personally I’d like to get rid of both of them, as I think they mask the important consideration of what discovery and transports are being linked/included for static.