-
Notifications
You must be signed in to change notification settings - Fork 37
Implemented changes as discussed on 2025-07-18 #1451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: abi_types_feature_request
Are you sure you want to change the base?
Implemented changes as discussed on 2025-07-18 #1451
Conversation
awillenbuecher-xq-tec
commented
Jul 18, 2025
- added Variant data type
- added Queue data type
- removed reflection from version 1.0
- removed restriction on equality of architecture
- made internal fields on ABI types private
The created documentation from the pull request is available at: docu-html |
docs/features/communication/abi_compatible_data_types/index.rst
Outdated
Show resolved
Hide resolved
It depends on some form of *type descriptions* being available to be able to interpret an unstructured sequence of bytes. | ||
|
||
Benefits of reflection include: | ||
|
||
* Consumers can perform additional consistency checks, because reflection provides a second, redundant description of the structure of the received data stream. | ||
* Recorded data can be translated into a human-readable format (e.g., JSON or CSV) without having to know the type definitions beforehand; this allows general-purpose data recording and transformation tools. | ||
* As a special case, if a data structure already contains *inline type descriptions* in the form of SOME/IP TLV tags, it doesn't need to be transformed before being sent over a SOME/IP connection. | ||
|
||
Inline Type Descriptions | ||
^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
||
An explicit transformation step between the in-memory representation and the SOME/IP+TLV format can – in theory – be avoided by adding TLVs to ABI compatible types. | ||
This approach, however, comes with significant downsides: | ||
|
||
* Adding inline type descriptions incurs a significant memory overhead across the board, and leads to worse cache behavior. | ||
* It mandates TLV for *all* instances of *all* ABI compatible types, even when TLV is not needed (for example, in a non-TLV SOME/IP gateway). | ||
* This might be mitigated by making TLV optional through a generic respectively a template parameter on the type declaration. | ||
* SOME/IP's specification of big-endianness is in conflict with the requirement of native-endianness for ABI compatible types, making the feasibility of this approach questionable. | ||
* SOME/IP doesn't support "unused" slots in dynamic arrays, so ABI compatible types containing *vectors* (which differentiate between the length and the capacity) couldn't be directly represented in SOME/IP anyway. | ||
|
||
Alternative Approach | ||
^^^^^^^^^^^^^^^^^^^^ | ||
|
||
Instead of inserting inline type descriptions into each instance of an ABI compatible type, the full type description can be made available to a consumer only once, either proactively or on request. | ||
The consumer decides if it uses or ignores this metadata. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep the alternative approach but move it to section "rejected ideas" below along with a description why we decided against it. This helps to avoid the same discussion twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done: Rejected Ideas
- added Variant data type - added Queue data type - removed reflection from version 1.0 - removed restriction on equality of architecture - made internal fields on ABI types private
a7dae32
to
df2e18c
Compare
df2e18c
to
d32e05d
Compare