approach idea: focus on the core Rust implementation

[carlocorradini]

I really like zerodds and the vision behind its broader ecosystem, including multi-language interoperability, CORBA integration, and related components.
However, in its current state (this is purely my personal opinion, so take it accordingly) I believe it would be more beneficial to focus primarily on Rust and the core crates.

Rust is still relatively new within the DDS ecosystem, and there is a strong need to establish a solid foundation first.
Once the Rust implementation is mature, well-tested and performant, it will be much easier to expand into other areas such as C/C++ bindings and additional components.

Focusing on Rust would not only help build a robust and reliable foundation, but also reduce the risk of spending limited development resources on crates or features that may see little to no adoption (nim programming language bindings).
Given that the community is still relatively small, concentrating efforts on the most critical pieces could provide the greatest long-term benefit.

I think the following crates are the most fundamental building blocks of the Rust ecosystem and deserve the highest priority:

• DDS core components such as dcps, security, serialization, deserialization, and the other foundational building blocks of the stack
• A DdsType macro for Rust to generate type information for all supported IDL types (struct, enum, union, etc.)
• An IDL generator that translates IDL files into Rust files (or merges everything into a single flat file). The generator should "simply" generate the corresponding Rust's modules, structs, enums, etc., with all the required #[derive(...)] attributes, including the DdsType derive described above. This approach keeps the DdsType trait implementation generation in a single crate and significantly simplifies the IDL generator
• An IDL build crate to generate Rust code at build time (build.rs). For simplification it wraps the IDL compiler

[SandraK82]

Thanks for the thoughtful proposal, Carlo. I agree with its central point: the core type, serialization and build-time generation path needs to be solid before the broader ecosystem can rely on it.

This work had already started before this issue; I only briefly hinted at it in #40. We are currently rebuilding the IDL and encoding/decoding architecture around a common typed model and transformation rules. The intended result is:

• one shared semantic model for IDL, validation and type metadata;
• one layout/wire decision layer for endianness, XCDR1/XCDR2 and extensibility;
• a much thinner Rust generator and build-time generation path;
• generated code that is compiled and tested against actual wire bytes;
• permanent cross-vendor interoperability tests rather than generator-output snapshots alone.

Rust is the reference implementation and the primary acceptance path for the new core. We do not, however, plan to make ZeroDDS Rust-only. The first architecture-validation set deliberately covers Rust, C, C++, Java and Python. Its purpose is to prove that all five consume the same semantics instead of growing separate serialization, TypeObject or layout implementations.

The rebuilt path is currently being validated against a substantially broader compatibility corpus than a two-vendor interoperability test. The matrix covers 335 IDL constructs and compares accepted constructs and generated octets against:

• Eclipse Cyclone DDS 11.0.1;
• RTI Connext DDS 7.7.0 / rtiddsgen 4.7.0;
• eProsima Fast DDS 3.6.1 / Fast CDR 2.3.5;
• OpenDDS 3.34.0;
• omniORB 4.3.3, TAO 2.5.24 and JacORB 3.9;
• ROS 2 Humble Fast RTPS and Cyclone DDS type-support paths;
• the rebuilt ZeroDDS language paths.

At the current stage, the external systems have not exposed an IDL construct that they accept but the rebuilt ZeroDDS model rejects. The remaining differences are predominantly in the opposite direction: constructs represented by the common model that individual external tools do not accept.

This matrix is a frontend, semantic and emitted-octet compatibility gate; it is not being presented as a substitute for live DDS interoperability. Live endpoint matching and typed delivery remain separate acceptance layers. In particular, the nested Robot scenario reported in #41 and #42 will be retained as a bidirectional live regression once the rebuilt stack reaches the corresponding runtime integration layer.

The additional language mappings remain part of the existing RC7 roadmap, but they will follow only after the rebuilt core has reached a stable public integration point.

The work is substantial and still in progress, so I do not want to present partial results as a finished solution. I will update this issue with the public commits, reproducible matrix and live interoperability evidence once the first integrated slice is ready.