You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to use Cap'n Proto as a serialization codec. It is fast. But also requires schemas to decode, nothing as nice for devs as easily readable json in the messages.
I could see this first used to pass Params between the cosmos SDK and the wasm module, as that is never exposed to the end user, rather used internally. If this shows it works, Individual contracts could decide to use either json or cap'n Proto for their storage and message formats (which are just opaque bytes to every level between client and server). It would make it a bit harder to call between contracts with different serialization, but in the end only require another import for the codec.
The text was updated successfully, but these errors were encountered:
If we want to migrate away from JSON for performance reasons, we probably switch to protobuf as this is what the ecosystem is familiar with already. However, no encoding changes are planned.
Requested by @aaronc
The idea is to use Cap'n Proto as a serialization codec. It is fast. But also requires schemas to decode, nothing as nice for devs as easily readable json in the messages.
I could see this first used to pass
Params
between the cosmos SDK and the wasm module, as that is never exposed to the end user, rather used internally. If this shows it works, Individual contracts could decide to use either json or cap'n Proto for their storage and message formats (which are just opaque bytes to every level between client and server). It would make it a bit harder to call between contracts with different serialization, but in the end only require another import for the codec.The text was updated successfully, but these errors were encountered: