IceOryx2 Message Type Plan

[ElliotHYLee]

Hello community, I'm just curious about the future direction of iox2 as I might migrate my local-IPC projects to iox2.

The current byte array message type in IOX2 is basically message serialization-agnostic (i.e, protobuf, flatbuffers, etc).

Yet, based on the current efforts on the message type-related codes in the project, I wondered if the maintainers plan to control the message types. I mean it's totally fine as long as the general byte array or vector is there.

In my personal opinion, if possible, Appach Arrow, a few primitives, and a byte array/vector might be all the users need. I just wanted to check if iox2 wouldn't dictate the message protocols and types in the future. I hope the current iox2's awesome shmem delivery system can be totally stand-alone and decoupled regardless of the data type or serialization protocol in the future, just as it is now. ;)

FYI, I'm from robotics. ROS1/2 can do a general byte array (btw, I saw iox 1 has dds middleware, anyways..). However, the entire framework is based on its own ROS Idle. Therefore, if I'm using the general byte array, then, ROS tools become useless. I think ROS's dictatorship on the message serialization blocks the scalability, while other devices send the data in flatbuffers and protobuf. To this end, I need to maintain the message conversion bridge whenever the message protocol is updated/created/deleted. This is a huge bottleneck on top of its limited choices of IPC middleware. And I was curious if Iox2 wouldn't repeat the dictatorship. :)

[elBoberido]

@ElliotHYLee iceoryx2 will remain data agnostic. At some point in the future we might add some conventions for data types in order to help tooling, but it will be opt-in and one can always use iceoryx2 with raw bytes. With conventions I mean to standardize some attributes that can be used to store information about the data type, like data layout or serialization format.

Our goal with iceoryx2 is to be as unopinionated as possible about the API, in order to not force a specific design/architecture on the user.

[ElliotHYLee]

@elBoberido I love the philosophy. Thanks!