Investigation on possible copying use cases in general

General purpose of this issue

In the performance & packaging group, we found that it is still a common practice to copy stuff like the GroundTruth or the SensorViewConfiguration in the models to output them aside of the actual model output.

However, this practice has some drawbacks aside of performance penalties like e.g. the reliability of such copies coming from models and not from the original source of the data.

With respect to OSI 4.0, we now question this practice in general and want to start a discussion here on possible use cases. Probably we can get rid of it at all, but it is also possible to keep it and allow it for specific use cases.

Affected parts of the standard

This discussion affects different aspects of the standard, so we collect the possible use cases for

OSI documentation, to describe good practice for copying and whether it makes sense at all.
OSMP examples to actually show good practice
OSI 4.0 and the ongoing discussion about a possible move to Flatbuffers.

Additional information regarding copying stuff in Flatbuffers

Our Flatbuffers application report states on p. 7:

Flutbuffers does not come with a deep copy function, so there is no easy way to copy table or entire buffers to a different buffer. With OSI it is currently common practice to copy the SensorView input of a sensor model to the SensorData output. As there is no standard function to do this with Flatbuffers, one has to be custom written.

Related to this discussion, there is an open issue in FlatBuffers for adding a copying feature that suggests to use nested FlatBuffers for such a purpose (if we decide to switch to FlatBuffers).

So let's start the discussion!

OpenSimulationInterface / open-simulation-interface