Skip to content
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

rework list of predefined encodings #1507

Open
milyin opened this issue Oct 3, 2024 · 1 comment · May be fixed by #1513
Open

rework list of predefined encodings #1507

milyin opened this issue Oct 3, 2024 · 1 comment · May be fixed by #1513
Labels
api fix Correct API breaking-change Indicates that the issue implies a breaking change (be it at compile time or at runtime) release Part of the next release

Comments

@milyin
Copy link
Contributor

milyin commented Oct 3, 2024

Describe the release item

There are several predefined encodings which became ambigious after serialization rework in #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
  • remove types ZENOH_INT8, ZENOH_INT16, etc
@milyin milyin added the release Part of the next release label Oct 3, 2024
@milyin
Copy link
Contributor Author

milyin commented Oct 3, 2024

@wyfo @kydos if this that you finally decided about this issue?

@milyin milyin added breaking-change Indicates that the issue implies a breaking change (be it at compile time or at runtime) api fix Correct API labels Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api fix Correct API breaking-change Indicates that the issue implies a breaking change (be it at compile time or at runtime) release Part of the next release
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

1 participant