Communication FT Weekly [2026-06-29]

[crimson11]

Participants

@JochenSatETAS
@MichaelSteffens17
@NEOatNHNG
@NemanjaTrifunovicRTRK
@rpreddyhv
@guejan
@Rahul-Sutariya
@sahithi-nukala
@lurtz
@Abhishek2581
@crimson11

Agenda

1. Status update SOME/IP
2. Status update Flatbuffers
3. Status update Rust API
4. Status Methods&Fields
5. Status GenericSkeleton
6. Status nothrow types
7. Status DDS gateway
8. Status IDL

Meeting Minutes

to (1)

@lurtz:

A lot of PRs waiting for review. I.e. there is currently a review bottleneck.
Currently awaiting committer-role for one of the contributors, which might ease the situation.
Otherwise no blockers.

to (2)

@JochenSatETAS:
PR is expected to come next week. No blockers.

to (3)

@rpreddyhv:

currently cleanup taking place:
eclipse-score/communication#602

New extensions (methods & fields-get-set) from the C++ binding get analyzed and Rust API proposals are now being created accordingly.

to (4)

@crimson11:
there are still a few PRs to be reviewed/waiting for being merged.
Some architectural changes had to be applied about, how move-semantics now works with Skeletons/SkeletonServiceElements as well as Proxies/ProxyServiceElements. This lead to some delay.
After the existing PRs are merged the entire feature is done.

to (5)

@crimson11:
Integration test for GenericSkeleton are now completed and architecturaly in a good shape..
Interim-Fix for the know issue we had in generic/typed-interaction is there and verified.
Midterm solution to make event/field binding layer type-agnostic has not yet started and there is also not yet any planning for it.

to (6)

There was a meeting including an update in the context of the original request.
See here: eclipse-score/baselibs#167 (comment)

to (7)

@crimson11 and @Abhishek2581:
Clarification: As laid out in the FR, both, a gateway and a binding solution will be supported.
The FR has been updated: #2997
Questions from last week have been answered by @Abhishek2581 -> see last weeks meeting minutes.

to (8)

We had (again) a discussion about the need for an IDL in the future. Obviously the following use cases

• Rust/C++ interop
• network bindings with dedicated serialization rules/requirements

will require an abstract IDL.
Then a short discussion started, whether then - based on an IDL - code-generation of proxy/skeleton code needs to happen from the IDL.
We clarified, that (at least in case of the C++ binding) the process would be:
IDL -> generate C++ service-interface-type -> apply existing C++ templates to "generate" proxy/skeleton classes.
I.e. we basically keep the existing C++-template based approach. We only extend it, that the service-interface C++ type needs not to behand-written (as of now), but can be generated out of an IDL.