Eclipse Cyclone DDS™ 0.5.0 (Eusebius)
Primary tabs
Fully backwards compatible with the following exceptions:
- a change in how implicitly created ("publisher" and "subscriber") entities are handled: they now never lose their "implicitness", and in consequence, are now deleted when their last child disappears rather than deleted when their one child disappears;
- the set of entities that can be attached to a waitset is now restricted to those owned by the parent of the waitset, before one was allowed to attach entities from different participants to the same waitset, which is tantamount to a bug;
- a participant entity now has a participant, so the "get_parent" operation no longer returns 0 for a participant because of the addition of two additional levels to the entity hierarchy: a domain, possibly containing multiple participants; and one that represents the entire library;
- the data from a reader for a built-in topic has been extended, breaking binary compatibility.
Acceptance of some malformed messages from certain implementations improved interoperability on the wire.
None. Given that Cyclone DDS is a middleware library aimed at developers, the absence of translations is not believed to be an obstacle to adoption, and besides the active people would not be able to do much in the way of internationalisation ...
Tier 1 platforms are Linux, macOS and Windows, and FreeRTOS is also supported. It is known to work on Solaris 2.6 and believed to be easy to port to most platforms, including many embedded ones.
Hardware dependency is limited to endianness (because of serialisation formats) and the availability of atomic operations. It is tested/known to work on x86, ARM and SPARC (in 32 and 64-bit variants), and so there is no reason to expect any problems on other common CPU architectures (e.g., PowerPC, MIPS, RISC-V).
There is a dependency on Java for preprocessing IDL and generating instructions for the serialiser, and additionally on Maven for building this preprocessor. Various people have raised concerns on this dependency, and work is underway to eliminate it by replacing the current, Java-based pre-processor by one written in C.
Language bindings are currently still limited to C, but a C++ is known to exist and expected to be donated quickly on the heels of this new preprocessor.