Hi Barry, thanks for bringing this up! JSON was one of the considered, but scrapped ideas; I'll explain why:
On Sat, 2019-09-28 at 20:13 -0400, Barry Duggan wrote: > Just thinking outside the box here, but what about JSON? It is well > defined, JSON is not really overly well-defined when it comes to how to transport raw samples, and many of those. There's one sorry-but-it-kills-that-option argument against JSON, by the way: If the origins of modern chaos theory have taught us anything, you don't want serialization to change your floating point numbers¹ (and that's the dominant data format, so that's kind of important here). JSON's text-based float format does exactly that, round. We could fiddle with the serializers in established JSON encoders, but we'd risk producing non-standards compliant JSON, and there goes your compatibility and well-definedness. > self documenting, That's actually kind of an anti-feature! We'd want data to fit into predefined schemata, rather than allowing arbitrary fields in arbitrary order. > easy to exchange between platforms and OS's, that's true > and supported natively by Python. That is a bonus, but it doesn't outweigh its downsides. > Yes, it requires parsing, but I don't > think that is a major drawback. Sadly: You'd be wrong! JSON parsing is compared to what we want to do with the data a pretty compute-intense job. Think of it like this: People will want to build things where half a million messages per second is not an implausible requirement. > Also it would not require any > documentation to define how it works! I think the main workload would be documenting how the thing we're building should be used, and that's pretty independent from how we encode messages beneath the surface :) Best regards, Marcus ¹ https://en.wikipedia.org/wiki/Edward_Norton_Lorenz#Chaos_Theory
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio