Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

[CEL]

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