Module node_record 

Phase 104.C.2 — multi-Node-per-Executor storage.

Mirrors the rclcpp pattern where a single Executor holds N Nodes via add_node(...). Each Node carries its own name/namespace + a reference to the Session that backs it + a default SchedContext (Phase 110) handles inherit unless overridden.

For Phase 104.C.2 we land the storage scaffold + the builder API. Multi-Session-per-Executor dispatch is a follow-up (Phase 104.C.3) — today every Node in this list resolves to the Executor’s primary session, which means node_builder.rmw(name) only accepts the same backend the Executor was opened against. Bridge use cases (two RMW backends concurrent in one Executor) light up when 104.C.3 adds the per-Node session ref.

Structs

NodeBuilder

Builder returned by Executor::node_builder(name). Chainable configuration; .build() registers the Node with the Executor and returns a NodeId.

NodeId

Opaque handle returned by Executor::node_builder(...).build(). Used in 104.C.3+ to disambiguate handle ownership when multiple Nodes coexist in one Executor.

NodeRecord

Per-Node metadata stored inside the Executor.

Functions

apply_qos_override_codes

Fold a node’s baked override codes into qos for one (topic, role). Thin alias over nros_rmw::QoSProfile::apply_override_codes — issue 0303 collapsed four copies of this match into that one.

Type Aliases

QoSOverrideCode

Issue #52 / 0303 — one baked QoS override, re-exported from nros-rmw where the single decoder lives. Kept as a name here because NodeRecord and the entry bake spell it. Issue 0303 — the wire form a baked QoS override travels in: (topic, role, policy, value), all primitives.