3 ms·
Hm it looks like it would satisfy a lot of binary data use cases, but so would MessagePack, CBOR, and probably a few dozen other formats. A design goal of QSN
by chubot 6y ago
Hm it looks like it would satisfy a lot of binary data use cases, but so would MessagePack, CBOR, and probably a few dozen other formats.
A design goal of QSN is to be human readable like JSON. You can view it at the terminal, in an editor, in an e-mail, or in the browser. IMO that fits more naturally with Unix and the web.
So I guess I should make clear that it's not only about "binary data", but it's that + a few other constraints.
- BerislavLopac 6y ago> A design goal of QSN is to be human readable like JSON. Well Ion has both text and binary encodings: https://amzn.github.io/ion-docs/docs/spec.html https://amzn.github.io/ion-docs/docs/spec.html
- chubot 6y agoI looked at it more. It has both a string type (which has \xHH escapes oddly specified as code points), and a binary type (which is specified as base64 in text format -- this is bad because base64 isn't human-readable despite being ASCII). The 2 different types makes it unsuitable for the use cases I'm targeting QSN at, which deal only with byte strings, which may be encoded in UTF-8 (like kernel APIs). I don't see what Ion adds over MessagePack, CBOR, or several other such formats... but that's a different discussion :)