Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Significant new features
Support for mixed-language programming by supporting multiple (de)serializers for a single topic in a single process. This way, a program that consists of, say, C and C++ can use a different representation of the data in C than in C++. Before, all readers/writers in the process would be forced to use the same representation (or perform an additional copy). Currently C is still the only natively supported language, but one can use an evolving-but-reasonable-stable interface to implement different mappings.
Improved QoS support: full support for deadline, lifespan and liveliness. The first is for generating notifications when a configured instance update rate is not achieved, the second for automatically removing stale samples, the third for different modes of monitoring the liveliness of peers.
Improved scalability in matching readers and writers. Before it used to try matching a new local or remote reader or writer with all known local & remote entities, now only with the right group with the correct topic name.
Improved tracing: discovery data is now printed properly and user samples have more type information allowing floating-point and signed numbers to be traced in a more readable form.
Extension of platform support
- Known to work on FreeBSD, CheriBSD
- Known to work with the musl C library
- Fixes multicasts to addresses also used by non-Cyclone processes (caused by accidentally linking with an old sockets library)
- Correct handling of non-English network interface names
The overall architecture is holding up just fine, but there remain many, mostly local, details that need reworking. This is an ongoing process, undertaken as a background activity while working towards covering all of the DDS specification famliy. The number of issues reported by people remains very low despite evidence of a growing user base, and this is also an indication that the fundamental architectural choices are sound.
No known issues.
The documentation is very basic but appears to be good enough for those who are willing to invest a bit and make a few educated guesses, based on the evidence of increasing usage and the questions that have been asked on GitHub. Presentation of the documentation and providing easy access to it (e.g., via readthedocs.io), as well as a proper website is still missing, but there are some indications that help will come.
How many users there would have been by now had the documentation been better is anyone's guess. Thus, it is one of the main points needing attention.
As it is middleware the intended audience is very minimal and there is no user interface to speak of.
- DCPS specification version 1.4 (with a more friendly API)
- DDSI specification version 2.3
This release is specifically aimed at matching the upcoming "Foxy Fitzroy" release of ROS2, where Cyclone DDS is one of 3 tier-1 middleware options. We're quite proud of this: at the time of the initial release of "Dashing" there was no support for Cyclone DDS at all, both other tier-1 middleware options were there from the beginning, and no other newcomers have even made it to tier-2.
The tireless promotion of Cyclone DDS in the ROS2 community by Mr. Joe Speed (in particular) has dramatically increased visibility and use of Cyclone DDS. Some rather well-known companies have chosen to use Cyclone DDS over the incumbent middleware implementations in the ROS2 ecosystem (https://iot.eclipse.org/adopters/?#iot.cyclonedds).
All this has led to more community involvement and more contributions from people outside the original circle. Examples include a port to a research operating system and fuzzing it to find bugs (the two bugs reported had both been discovered and fixed independently, fortunately).