Communication CFT Weekly [2025-11-24]

[LittleHuba]

Participants

Agenda

1. Should we discuss a migration to different communication APIs at this point in the project? (CommonAPI, raised by @mina-hamdi)
2. Change: add component binary config loader #1935 (raised by @arsibo)

[mina-hamdi]

Hi @LittleHuba , the colleague who will present the CommonAPI topic tomorrow is proposing this alternative title for the topic "Combining CommonAPI with mw::com/LoLa IPC as an implementation option for the communication feature set".

[crimson11]

Feedback from Jochen Speck (ETAS):
We from ETAS-side would be interested to get some idea when methods will be available and when and how we can contribute to async methods as we have an internal application depending on it.
-> will be discussed today.

[mina-hamdi]

Hello, here is the slides deck presented by Valeo for the first topic regarding CommonAPI and mw::com.
Combining CommonAPI with mw__com_LoLa .pdf

[crimson11]

Meeting Minutes

Participants

@crimson11
@ZoranCutura
@piotrchodorowski
@alexandruiulian10
Michael Taenzer (ETAS)
@Abhishek2581
@FScholPer
Sebastian Grobosch (ETAS)
Jochen Speck (ETAS)
@arsibo
Hisham Al-Saeed
Mike Haller (ETAS)
Ahmed ElAbyad

Topics

Presentation by Valeo of CommonAPI. Showing benchmarking data of comaprison CommonAPI/mw::com for a payload roundtrip.
Comparably high latency of mw::com for small messages is due to the fact, that mw::com in this case uses TWO separate unidirectional channels (QNX) instead of one bi-directional. Needs to be re-assessed, when score::mw::com has method support.

Proposal of Valeo was to go with CommonAPI instead of score::mw::com as it "already has all the features" and a zero-copy API/implementation can be easily added.
No decissions taken. Valeo wants to bring this discussion to architecture FT.