search

cbor / cbor.github.io

cbor.io web site
74 stars 33 forks source link

discuss JSON <--> CBOR roundtripping on the website. #11

Closed jbenet closed 8 years ago

jbenet commented 8 years ago

a major reason to adopt CBOR is as a way to represent JSON on the wire + on storage. it would be nice to very clearly see what the problems with roundtripping CBOR -> JSON -> CBOR and JSON -> CBOR -> JSON might be.

Type1J commented 8 years ago

From a JavaScript perspective:

There are not just 2 representations, there are 3: JSON, CBOR, and unserialized objects that are being used. The unserialized objects have many more types than when JSON was initially created.

From what I can tell, JSON is less equipped with types than CBOR to transparently represent serialization of some common JavaScript objects, which leads to either intermediate representations, which can be inefficient, or non-transparent extensions to JSON, which is efficient, and more common in the code that I see. See EJSON for an example of how JSON can be non-transparently extended in order to accommodate the full gamut of what is used on the wire for at least 1 server/client framework: Meteor. CBOR's extension mechanism has already standardized the date representation, and binary blobs, which is what EJSON tries to shoehorn into JSON.

So, the problems that roundtripping in to or out of CBOR and JSON would be that JSON has less types, so type information may be lost in that direction. However, using something like EJSON, you could make sure that the JSON representation retains all of the type information that it needs to be isomorphic with CBOR, and an unserialized from.

jbenet commented 8 years ago

@Type1J indeed. Thanks. And yes, the EJSON <--> CBOR 1:1 relationship should be emphasized. I think getting to 1:1 mapped entities is a big win. (Also, reminding people to allow "canonicalizing" (sorting keys) encoded structures, so they hash equally...)