Dedicated meeting to discuss REP 0157: Wednesday, 4 November 2026

Projects
2

Unclear if I can make it to the meeting, but wanted to forward a few high-level questions/comments.

1. API migration

The prototype puts the new types in a parallel namespace (sensor_msgs::msg::experimental::Image). The underlying question from #22 is still open: should the view be an API-compatible drop-in with member access, or a distinct type with accessors and a deprecation cycle? See William’s comment and Michel’s reply that this needs an executive decision.

Also, what is the plan for moving experimental:: to the default?

2. Relationship to rosidl::Buffer / buffer backends

In January I asked that this be reconciled with the native buffers work (Discourse thread). That work has since landed in rolling and Lyrical:

The two efforts overlap in a few places:

  • Both change the generated C++ type for uint8[].
  • Both add loan or negotiation plumbing to rmw_fastrtps.
  • Both describe where memory lives: rosidl_memory_t.attributes in REP 157, and BufferMemory in rosidl#990.

Can the REP state explicitly how the two relate? In particular could the uint8[] field of a 157 view be a rosidl::Buffer backed by the loaned region?

I’d like to end up with one model for memory location rather than two.

3. Scope

Is the REP meant to standardize only the rmw API additions and the type-support operation table? Or does it also cover the generated C++ and Python view APIs?

4. Size and phasing

The reference implementation is large. Not counting tests, it is roughly 45k lines, and only about 8k of that is generator code. Most of the rest is container runtimes for C, C++ and Python plus the XCDR library. The diffs against upstream Jazzy:

Some questions on phasing:

  • Could a first phase be C++ only? The C message runtime and its generator don’t appear to be on the C++/Python path.
  • Could most of it live out of tree as experimental packages, with only the rmw, rcl and client library plumbing going into core repos?
  • Could xcdr_buffers use Fast CDR for the serialize/deserialize path instead of its own reader and writer?
1 Like