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

51–60 of 106 posts

Re: From XML to JSON to CBOR

#51

Post by 8n4vidtmkvmk »

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.

Doesn't capn proto win hands down on compute?

I haven't used it, but I thought that was the big claim.

Re: From XML to JSON to CBOR

#52

Post by gethly »

dylan604 wrote: post #42
gethly wrote: post #28

I wish browsers would support CBOR natively so I could just return CBOR instead of JSON(++speed --size ==win) and not have to be concerned with decoding it or not being able to debug requests in dev console.

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?

That is true. Basic content encoding works very well with json but that still means there is the compression step, which would not be necessary with CBOR as it is already a binary payload. It would allow faster response and delivery times natively. Of course, we are talking few ms, but I say why leave those ms on the floor?

I guess i'm just shouting at the clouds :D

Re: From XML to JSON to CBOR

#53

Post by stronglikedan »

kentonv wrote: post #46
mikepurvis wrote: post #44

Earlier quoted context omitted.

Notably missing is a comparison to Cap'n Proto, which to me feels like the best set of tradeoffs for more binary interchange needs. I honestly wonder sometimes if it's held back by the name— I love the campiness of it, but I feel like it could be a barrier to being taken seriously in some environments.

> I feel like it could be a barrier to being taken seriously in some environments. Working as intended. ;)

man I love HN lol

Re: From XML to JSON to CBOR

#54

Post by sevensor »

_the_inflator wrote: post #40

Love or hate JSON, the beauty and utility stem from the fact that you have only the fundamental datatypes as a requirement, and that's it. Structured data that, by nesting, pleases the human eye, reduced to the max in a key-value fashion, pure minimalism. And while you have to write type converters all the time for datetime, BLOBs etc., these converters are the real reasons why JSON is so useful: every OS or framewor…

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?

Basically I think formats with syntax typed primitives always run into this problem: even if the encoder and decoder are consistent with each other about what the values are, the receiver still has to decide whether it can use the result. This after all is the main benefit of a library like Pydantic. But if we’re doing all this work to make sure the object is correct, we know what the value types are supposed to be on the receiving end, so why are we making a needlessly complex decoder guess for us?

Re: From XML to JSON to CBOR

#55

Post by aidenn0 »

I admit I got nerd-sniped here, but the table for floats[1] suggests that 10000.0 be represented as a float32. However, isn't it exactly representable as 0x70e2 in float16[2]? There are only 10 significant bits to the mantissa (including the implicit 1), while float16 has 11 so there's even an extra bit to spare.

1: https://cborbook.com/part_1/practical_introduction_to_cbor.h...

2: i.e. 1.220703125×2¹³

Re: From XML to JSON to CBOR

#56

Post by aidenn0 »

sevensor wrote: post #54
_the_inflator wrote: post #40

Love or hate JSON, the beauty and utility stem from the fact that you have only the fundamental datatypes as a requirement, and that's it. Structured data that, by nesting, pleases the human eye, reduced to the max in a key-value fashion, pure minimalism. And while you have to write type converters all the time for datetime, BLOBs etc., these converters are the real reasons why JSON is so useful: every OS or framewor…

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.

Re: From XML to JSON to CBOR

#57

Post by kentonv »

kentonv wrote: post #46
mikepurvis wrote: post #44

Earlier quoted context omitted.

Notably missing is a comparison to Cap'n Proto, which to me feels like the best set of tradeoffs for more binary interchange needs. I honestly wonder sometimes if it's held back by the name— I love the campiness of it, but I feel like it could be a barrier to being taken seriously in some environments.

> I feel like it could be a barrier to being taken seriously in some environments. Working as intended. ;)

In all seriousness: I develop Cap'n Proto to serve my own projects that use it, such at the Cloudflare Workers runtime. It is actually not my goal to see Cap'n Proto itself adopted widely. I mean, don't get me wrong, it'd be cool, but it isn't really a net benefit to me personally: maybe people will contribute useful features, but mostly they will probably just want me to review their PRs adding features I don't care about, or worse, demand I fix things I don't care about, and that's just unpaid labor for me. So mostly I'm happy with them not.

It's entirely possible that this will change in the future: like maybe we'll decide that Cap'n Proto should be a public-facing part of the Cloudflare Workers platform (rather than just an implementation detail, as it is today), in which case adoption would then benefit Workers and thus me. At the moment, though, that's not the plan.

In any case, if there's some company that fancies themselves Too Serious to use a technology with such a silly name and web site, I am perfectly happy for them to not use it! :)

Re: From XML to JSON to CBOR

#58

Post by kentonv »

8n4vidtmkvmk wrote: post #51
surajrmal wrote: post #38

Earlier quoted context omitted.

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.

Doesn't capn proto win hands down on compute? I haven't used it, but I thought that was the big claim.

Not necessarily.

Cap'n Proto serialization can be a huge win in terms of compute if you are communicating using shared memory or reading huge mmaped files, especially if the reader only cares to read some random subset of the message but not the whole thing.

But in the common use case of sending messages over a network, Cap'n Proto probably isn't a huge difference. Pushing the message through a socket is still O(n), and the benefits of compression might outweigh the CPU cost. (Though at least with Cap'n Proto, you have the option to skip compression. Most formats have some amount of compression baked into the serialization itself.)

Note that benchmarks vary wildly depending on the use case and the type of data being sent, so it's not really possible to say "Well it's N% faster"... it really depends. Sometimes Protobuf wins! You have to test your use case. But most people don't have time to build their code both ways to compare.

I actually think Cap'n Proto's biggest wins are in the RPC system, not the serialization. But these wins are much harder to explain, because it's not about speed, but instead expressiveness. It's really hard to understand the benefits of using a more expressive language until you've really tried it.

(I'm the author of Cap'n Proto.)

Re: From XML to JSON to CBOR

#59

Post by aidenn0 »

mikepurvis wrote: post #44
ognyankulev wrote: post #13

Earlier quoted context omitted.

The fact that the long article misses to make the historical/continuation link to MessagePack is by itself a red flag signalling a CBOR ad. Edit: OK, actually there is a separate page for alternatives: https://cborbook.com/introduction/cbor_vs_the_other_guys.htm...

Notably missing is a comparison to Cap'n Proto, which to me feels like the best set of tradeoffs for more binary interchange needs. I honestly wonder sometimes if it's held back by the name— I love the campiness of it, but I feel like it could be a barrier to being taken seriously in some environments.

Doesn't Cap'n Proto require the receiver to know the types for proper decoding? This wouldn't entirely disqualify it from comparison, since e.g. protobufs are that way as well, but they make it less interesting for comparing to CBOR, which is type-tagged.

Re: From XML to JSON to CBOR

#60

Post by mikepurvis »

kentonv wrote: post #57
kentonv wrote: post #46

Earlier quoted context omitted.

> I feel like it could be a barrier to being taken seriously in some environments. Working as intended. ;)

In all seriousness: I develop Cap'n Proto to serve my own projects that use it, such at the Cloudflare Workers runtime. It is actually not my goal to see Cap'n Proto itself adopted widely. I mean, don't get me wrong, it'd be cool, but it isn't really a net benefit to me personally: maybe people will contribute useful features, but mostly they will probably just want me to review their PRs adding features I don't care…

Ha, I wondered if you'd comment. Yeah that's a reasonable take.

I think for me it would be less about locking out stodgy, boring companies, and perhaps instead it being an issue for emerging platforms that are themselves concerned with the optics of being "taken seriously". I'm specifically in the robotics space, and over the past ten years ROS has been basically rewritten to be based around DDS, and I know during the evaluation process for that there were prototypes kicked around that would have been more webtech type stuff, things like 0mq, protobufs, etc. In the end the decision for DDS was made on technical merits, but I still suspect that it being a thing that had preexisting traction in aerospace and especially NASA influenced that.

Post reply on HN