In short, Iroha supports arbitrary JSON payloads for certain actions. In SCALE they are encoded as JSON strings (JsonString type), while in JSON format they are inlined as values.
This is a proposal of an alternative solution: introduce as SCALE-native JsonValue type, encoded not as a string, but directly as an enum:
Compact encoding of JSON - no need to encode "[{}], characters & whitespace
Possibly faster deserialisation - needs benchmarking and careful implementation
Consistency in the schema - JsonValue represents f
Downsides
Needs custom implementation
Why it is String now
AFAIK the initial choice of string representation for JSON values is an efficiency concern: we don't want to pay for extra (de)serialization while transmitting data to/from WASM smartcontracts.
Basically, string was used as a way to have lazy encoding of data, as requested.
I think it should be possible to achieve lazy encoding in a more direct way with some sort of Lazy<T> container, making it both more explicit and flexible.
Context
Continuation of:
4900
5012
In short, Iroha supports arbitrary JSON payloads for certain actions. In SCALE they are encoded as JSON strings (
JsonString
type), while in JSON format they are inlined as values.This is a proposal of an alternative solution: introduce as SCALE-native
JsonValue
type, encoded not as a string, but directly as an enum:_this is a literal copy of
serde_json::Value
_Benefits
"[{}],
characters & whitespaceJsonValue
represents fDownsides
Why it is String now
AFAIK the initial choice of string representation for JSON values is an efficiency concern: we don't want to pay for extra (de)serialization while transmitting data to/from WASM smartcontracts.
Basically, string was used as a way to have lazy encoding of data, as requested.
I think it should be possible to achieve lazy encoding in a more direct way with some sort of
Lazy<T>
container, making it both more explicit and flexible.