-
Notifications
You must be signed in to change notification settings - Fork 37
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
Support for human-readable formats? #37
Comments
This crate is just about the serde internal data format and does not control how the format exposes it. Many human-readable formats only have the option of using a list of integers, since using base64 would make the value a string. The Ron format will serialize bytes using base64. You can, of course, force a specific string encoding like hex or base64, but then it will be stored as a string in the serialized form. There are already many crates offering this which you can use very similar to |
Well, yes, it will pass the data as a string to the specific format implementation. There will be some inefficiency if the format supports bytestrings natively, but "no encoding" can be one of the options.
Could you name some? And the problem is that I cannot use both |
Sure, quick search for the keywords serde, base64, hex reveals at least these crates If you need to rely on |
Do not support efficient serialization in binary formats.
No base64 support, and never will be given the name.
If you are referring to "De/Serializing a type using the Display and FromStr traits", this also means no binary format support. (And, also, one would have to use wrapper types)
Weird composition required with a lot of boilerplate.
Specifically focused on constant-timeness. To summarize, since |
CosmWasm has special types for human redabale base64 and hex stings. So it is useful in some areas to have. |
For people encountering this issue, I've published https://crates.io/crates/serde-encoded-bytes. I think this is not going to be implemented in |
While this crate helps serialize bytes in binary formats efficiently, human-readable formats will still have them as vectors of integers. Is efficient serialization in human-readable formats something potentially fitting for this crate, or should it be implemented elsewhere?
That may include:
The text was updated successfully, but these errors were encountered: