So here's how I think this fits into all the other different types of data serialization:<p>Schema-ful, copying:
Protobuf, Thrift, plenty more<p>Schema-ful, zero-copy: Cap'n'proto, Flatbuffers<p>Schema-less, copying: Json (binary and other variants included), XML<p>Schema-less, zero-copy: Flexbuffers (Any others? This seems new to me)
> if you supply a buffer that actually contains a float, or a string with numbers in it, it will convert it for you on the fly as well, or return 0 if it can't. If instead you actually want to know what is inside the buffer before you access it, you can call root.GetType() or root.IsInt() etc.<p>I've started to prefer functions that are explicit about their error cases and have interfaces that make it obvious about what errors you'd want to handle. Unexpectedly getting a zero when you get garbage data may cause issues.<p>Thinking about it, zero is often used as a success code: ERROR_SUCCESS is 0x0 on Windows. So garbage in, ERROR_SUCCESS out??<p>Something like:<p><pre><code> value, err = root.AsInt64();
</code></pre>
makes it clear you have an error path. You can still ignore `err`, like when you are moving fast and breaking things or it's somehow certain to always succeed, but it's clear that there's an unhandled error path.
<a href="https://google.github.io/flatbuffers/flatbuffers_white_paper.html" rel="nofollow">https://google.github.io/flatbuffers/flatbuffers_white_paper...</a> has the “why”, if anyone is curious.
I'm looking to replace our current Boost.Serialization code with something else. I have the following requirements:<p>- serialisation cannot be intrusive (i.e. I don't want a class definition to be generated from a schema file)<p>- zero copy<p>- some sort of versioning so any accidental message version mismatch between sender and receiver doesn't cause a crash / undefined behviour.<p>- many language support<p>Protobufs are intrusive, so that rules them out.
JSON is just too verbose and slow.
MessagePack looked like the most promising path to pursue at the moment. Flatbuffers look quite similar.
I wonder how it compares to messagepack's zero copy serializer: <a href="https://blog.treasuredata.com/blog/2011/11/21/messagepack-the-missing-serializer/" rel="nofollow">https://blog.treasuredata.com/blog/2011/11/21/messagepack-th...</a> ?
I wish Google open sourced RecordIO instead (or in addition). People reinvent this particular bicycle, poorly, pretty much in every project where engineers are smart enough to introduce a _structured_ application log.