On: Mark – A simple and unified notation for both obje...

[brianolson]

If you want a better JSON, try binary-json "Concise Binary Object Representation" RFC 7049 http://cbor.io/

[imtringued → brianolson]

You either go with JSON because everything talks JSON or you go with something that doesn't have an explicit parsing step like flatbuffers or capnproto.

If you don't care about parsing CPU efficiency then gzipped JSON beats protobuffers, CBOR, etc when you care about bytes sent over the wire.

If you care about CPU efficiency then protobuffers, CBOR, etc are worse than flatbuffers or capnproto.

There is not a lot of space for a new standard between these two existing categories.

[kentonv → imtringued]

> gzipped JSON beats protobuffers, CBOR, etc when you care about bytes sent over the wire.

Gzipped JSON does not beat gzipped Protobufs in message size. Comparing gzipped JSON to uncompressed Protobuf doesn't make sense.

[henryluo → brianolson]

Thanks for suggesting CBOR. Mark shall definitely have some binary representation, like BSON or CBOR, in future.

[nailer → brianolson]

My vote is for CSON: https://github.com/bevry/cson

[bringtheaction → nailer]

I'd heard of CSON before. I didn't remember hearing about CBOR (but I had an implementation of CBOR already starred on GitHub apparently). However, given the following:

> CBOR is defined in an Internet Standards Document, RFC 7049. The format has been designed to be stable for decades.

I see no reason to go with CSON over CBOR. In fact just the opposite.

[nailer → bringtheaction]

I'd suggest something like CSON for display and editing (with Link items for binary data), CBOR for transmission.