(How) should data types be serialized? about carp.core-kotlin HOT 2 CLOSED

After picking up on this discussion, we have decided that, although there is value in having 'data type hierarchies', rather than a simple data type class with a 'namespace' and 'name' field, it is premature to try to design such a hierarchy at this point in time.

The following potential benefits still hold:

Any additional data in data types is likely only needed once we want to start specifying 'secondary' data streams which process other data streams on the device, e.g., higher-order interpretations of data. If we want to write triggers which are reusable for 'custom' data streams they will need 'some' info on how to interpret said data; this was the initial purpose of a 'data type' definition.

But, it is hard to imagine exactly how said 'generic' processing of data would look like at this point in time (thus risking implementing complex data type hierarchies which turn out to be useless in the future), and, it is hard to assess whether alternate implementations would be just as useful in the future. For example, by having a registry of 'data parsers' which know how to extract/prepare data to common formats to be consumed by generic components in the infrastructure.

Thus, in conclusion, for now, we have decided to remove data type hierarchies and only use a single DataType class with the sole purpose of uniquely identifying the data (how it should be uploaded, what data can be measured). This also answers the question 'how should these be serialized', as all that remains is the identifier.

from carp.core-kotlin.

Polymorphism for DataType is removed in ac4c010

from carp.core-kotlin.