zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks.
There are several predefined encodings which became ambigious after serialization rework in https://github.com/eclipse-zenoh/zenoh/issues/1474. The main reason of ambiguity is that the prefix ZENOH_ for encoding doesn't say anything is serialization used or not.
E.g. is ZENOH_STRING means that ZBytes::to_string() was used or string was serialized into ZBytes. The difference is important: in second case the string is additionally prefixed by length.
Same for ZENOH_BYTES value: is it ZBytes::to_bytes() or serialization of vector of u8. Difference is the same: just to_bytes() doesn't add any prefix
The proposal is to
keep encodings ZENOH_STRING and ZENOH_BYTES, they should correspond to ZBytes::to_string(), ZBytes::to_bytes()
add type ZENOH_SERIALIZED. it's suffix can be used to store serializing schema
Describe the release item
There are several predefined encodings which became ambigious after serialization rework in https://github.com/eclipse-zenoh/zenoh/issues/1474. The main reason of ambiguity is that the prefix
ZENOH_
for encoding doesn't say anything is serialization used or not.E.g. is
ZENOH_STRING
means thatZBytes::to_string()
was used or string was serialized intoZBytes
. The difference is important: in second case the string is additionally prefixed by length. Same forZENOH_BYTES
value: is itZBytes::to_bytes()
or serialization of vector ofu8
. Difference is the same: justto_bytes()
doesn't add any prefixThe proposal is to
ZENOH_STRING
andZENOH_BYTES
, they should correspond toZBytes::to_string()
,ZBytes::to_bytes()
ZENOH_SERIALIZED
. it's suffix can be used to store serializing schemaZENOH_INT8
,ZENOH_INT16
, etc