Communication CFT Weekly [2026-05-11]

[crimson11]

Participants

@sahithi-nukala
@JochenSatETAS
@NEOatNHNG
@lurtz
@bharatGoswami8
@Abhishek2581
@ShoroukRamzy
@Rahul-Sutariya
@Thomas-Mikhael
@NemanjaTrifunovicRTRK
@rudresh-systream
@Rutuja-Patil-Bosch
@alberto-s-avila
@crimson11

Agenda

1. Status update SOME/IP
2. Status update Flatbuffers
3. Status update CI
4. Status update Rust API
5. Status Methods&Fields
6. Status GenericSkeleton
7. Upcoming IDL discussions

Meeting Minutes

to (1)

@lurtz : Interface changes to avoid heap allocation are underway/in review

to (2)

@JochenSatETAS: Concept finalization. Soon to be reviewed.

to (3)

@crimson11: Integration tests under //score/mw/com/test/<testname>/integration can be run either under Linux (default config) or QNX (--config=qnx_x86_64). Tests currently don't apply (within the py-files) target (Linux/QNX) specific arguments/behaviour. This might need to be changed.

to (4)

@bharatGoswami8:

• Working on Rust specific extension to support timeouts on the "event-receive-handler".
• This lead to a short discussion about this functionality and the conclusion, that this is a clear feature extension opposed to the C++ API.
• Some compile issues with acl library seem still to exist.

to (5)

@crimson11: Still some PRs are missing. Final adjustment of Field API signatures with respect to enable/disable Get/Set/Notifier support gets implemented. Now using template-arg-list of tag-types WithGetter, WithGetter, WithNotifier, which seems to be the most user-friendly approach, when designing service-interfaces with fields.

to (6)

@crimson11: Integration tests are there. Need to be reviewed. Will take care about this.
We have a short-term bug-fix available for the interoperability bug between GenericSkeleton and TypedProxy.
We will set up a meeting between Valeo and BMW to discuss potential long-term bugfix solution for the issue. (hint: going towards a completely type-erased storage on binding level - as we currently already have with methods).

to (7)

When talking about the input of @MichaelSteffens17 from last week about introduction of new container types for use in user-data-types being exchanged via score::mw::com the following ca,me up:

1. 1st the C++ part of the agreed ABI compatible data-types need to be implemented (the RUST side is already there)
2. Then any new data-type proposal has to be checked/discussed regarding ABI compatibility.
3. This might also lead to IDL discussion. But general consensus was, that we should try to separate IDL discussion as far as possible. Up to this point (RUST/C++ interop) we managed to discuss without an IDL introduction. We should keep this.