Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From XML to JSON to CBOR

cborbook.com

Post reply on HN
Print view View original

61–70 of 106 posts

Re: From XML to JSON to CBOR

#61

Post by aidenn0 »

camgunz wrote: post #41

Oh good, another CBOR thread. Disclaimer: I wrote and maintain a MessagePack implementation. I've also bird dogged this for a while, HN search me. Mostly, I just want to offer a gentle critique of this book's comparison with MessagePack [0]. > Encoding Details: CBOR supports indefinite-length arrays and maps (beneficial for streaming when total size is unknown), while MessagePack typically requires fixed collection c…

> ...awkwardly, streaming is a protocol level feature, not a data format level feature.

Indeed. I recall that tnetstrings were intentionally made non-streamable to discourage people from trying to do so: "If you need to send 1000 DVDs, don't try to encode them in 1 tnetstring payload, instead send them as a sequence of tnetstrings as payload chunks with checks and headers like most other protocols"

> Warning: I have a big rant about the tag registry. > ...

I completely agree with your rant w.r.t. automated decoding. However, a global tag registry can still potentially be useful in that, given CBOR encoded data with a tag that my decoder doesn't support, it may be easier for a human to infer the intended meaning. Some types may be very obvious, others less so.

e.g. Standardized MIME types are useful even if no application supports every one of them.

Re: From XML to JSON to CBOR

#62

Post by hvb2 »

naikrovek wrote: post #50
hvb2 wrote: post #21

Earlier quoted context omitted.

I assume you mean as an exercise? Not for actual use in any production system? If you did mean for production use, I assume you also implement your own encryption, encoding schemes and everything else?

i write my own binary formats because they're fast and small. yes, in production. partly because it's just as easy as anything else for me now, partly because it doesn't require any dependencies at all, and partly to show others just how easy it is, because i think people are unnecessarily afraid of this. no i don't write my own encoding or encryption. why the hell would anyone use json for everything, and why would…

I didn't say anywhere that we should use json for everything.

I think most people would go with something standard and documented. If you work in a team it helps if you can hire people that are familiar with tech or can read up on it easily.

And in general, unless you can show that your formatter is an actual hot path in need of optimization, you've just added another piece of code in need of care and feeding for no real gain.

Most devs/applications are fine with protobuf or even Json performance. And solving that problem is not something they can or should do.

If you write something like that just to prove a point, good for you. Also I would never want to be on the same team

Re: From XML to JSON to CBOR

#63

Post by dylan604 »

8n4vidtmkvmk wrote: post #49
dylan604 wrote: post #42

Earlier quoted context omitted.

JSON + compression (++speed --size ==win) your server can do this natively for live data. your browser can decompress natively. and ++human-readable. if you're one of those that doesn't want the user to read the data, then maybe CBOR is attractive??? but why would you send data down the wire that you don't want the user to see? isn't the point of sending the data to the client is so the client can display that data?

It's still not attractive to hide data from the user. Unless it's encrypted, the user can read it.

i think i'm using a different meaning of "seeing". to the user, it won't be plain text that is human readable. unencrypted CBOR byte data might as well be encrypted to the end user.

Re: From XML to JSON to CBOR

#64

Post by neutrinobro »

markisus wrote: post #23
naikrovek wrote: post #19

people are just straight up afraid to write their own binary formats, aren't they. it's not hard, it's exactly like creating your own text format but you write binary data instead of text, and you can't read it with your eyes right away (but you can after you've looked at enough of it.) there is nothing to fear or to even worry about; just try it. look up how things like TLV work on wikipedia. you can do just about a…

CBOR has some stuff that is nice but would be annoying to reimplement. Like using more bytes to store large numbers than small ones. If you need a quick multipurpose binary format, CBOR is pretty good. The only alternative I’d make manually is just memcpy the bytes of a C struct directly to disk and hope that I won’t encounter a system with different endianness.

These days you don't have to worry about endianness much (unless you dealing with raw network packets). However, you do need to worry about byte-padding. Different compilers/systems will place byte padding between items in your struct differently (depending on the contents and ordering of items), and if you are not careful the in-memory or on-disk placement of struct data elements can be misaligned on different systems. Most systems align to a 8-byte boundary, but that isn't guaranteed.

Re: From XML to JSON to CBOR

#65

Post by dang »

Related. Others?

Begrudgingly Choosing CBOR over MessagePack - https://news.ycombinator.com/item?id=43229259 - March 2025 (78 comments)

MessagePack vs. CBOR (RFC7049) - https://news.ycombinator.com/item?id=23838565 - July 2020 (2 comments)

CBOR – Concise Binary Object Representation - https://news.ycombinator.com/item?id=20603378 - Aug 2019 (71 comments)

CBOR – Concise Binary Object Representation - https://news.ycombinator.com/item?id=10995726 - Jan 2016 (36 comments)

Libcbor – CBOR implementation for C and others - https://news.ycombinator.com/item?id=9597198 - May 2015 (5 comments)

CBOR – A new object encoding format - https://news.ycombinator.com/item?id=6932089 - Dec 2013 (9 comments)

RFC 7049 - Concise Binary Object Representation (CBOR) - https://news.ycombinator.com/item?id=6632576 - Oct 2013 (52 comments)

Re: From XML to JSON to CBOR

#66

Post by sevensor »

aidenn0 wrote: post #56
sevensor wrote: post #54

Earlier quoted context omitted.

My complaint about JSON is that it’s not minimal enough. The receiver always has to validate anyway, so what has syntax typing done for us? Different implementations of JSON disagree about what constitutes a valid value. For instance, is {“x”: NaN} valid JSON? How about 9007199254740993? Or -.053? If so, will that text round trip through your JSON library without loss of precision? Is that desirable if it does? Basic…

NaN is not a valid value in JSON. Neither are 0123 or .123 (there must always be at least one digit before the decimal marker, but extraneous leading zeroes are disallowed). JSON was originally parsed in javascript with eval() which allowed many things that aren't JSON through, but that doesn't make JSON more complex.

That’s my point, though! I’ve run into popular JSON libraries that will emit all of those! 9007199254740993 is problematic because it’s not representable as a 64 bit float. Python’s JSON library is happy to write it, even though you need an int to represent it, and JSON doesn’t have ints.

Edit: I didn’t see my thought all the way through here. Syntax typing invites this kind of nonconformity, because different programming languages mean different things by “number,” “string,” “date,” or even “null.” They will bend the format to match their own semantics, resulting in incompatibility.

Re: From XML to JSON to CBOR

#67

Post by Zardoz84 »

surajrmal wrote: post #38
nabla9 wrote: post #26

CBOR is when you need option for very small code size. If you can always use compression, CBOR provides no significant data size improvement over JSON. With small code size it beats also BSON, EBML and others.

Or compute. Compression isn't free, especially on power constrained devices. At scale power and compute also have real cost implications. Most data centers have long been using binary encoding formats such as protobuf to save on compute and network bandwidth. cbor is nice because it's self describing so you can still understand it without a schema, which is a nice property people like about json.

gzip, deflate, brotli ?

Re: From XML to JSON to CBOR

#69

Post by teatro »

JoelJacobson wrote: post #68

Fun fact: CBOR is used within the WebAuthn (Passkey) protocol. To do Passkey-verification server-side, I had to implement a pure-SQL/PLpgSQL CBOR parser, out of fear that a C-implementation could crash the PostgreSQL server: https://github.com/truthly/pg-cbor

That’s why I’m wondering if there is an actual CBOR encoder in the browsers? I mean, there must be one, or am I wrong?

Re: From XML to JSON to CBOR

#70

Post by zokier »

maxbond wrote: post #35
zbendefy wrote: post #5

How different is CBOR compared to BSON? Both seem to be binary json-like representations. Edit: BSON seems to contain more data types than JSON, and as such it is more complex, whereas CBOR doesn't add to JSON's existing structure.

I think parsing BSON is simpler than parsing JSON, BSON has additional types but the top level is always a document. Whereas the following are all valid JSON: - `null` - `"hello"` - `[1,2,NaN]` Additionally, BSON will just tell you what the type of a field is. JSON requires inferring it.

NaN is not part of JSON by any spec. Top level scalar values were disallowed by RFC 4627.
Post reply on HN