I suggest to compare also against this .
The author, Kenton Varda, was the primary author of Protocol
Buffers version 2, which is the version that Google released
I just had a look at Cap'n Proto. From what I can see in the
encoding spec, performance of ION will be comparable.
Cap'n Proto claims to be "infinitely faster" than Google Protocol
Buffers, but that is only if you do not pack the CP data - in
which case it will transfer slower over the network. CP solves
that using packing - but then you are back to serialization /
deserialization, and the original promise of being "inifinitely
faster" is gone.
Cap'n Proto also has the "problem" that its messages require an
external schema. To iterate through a Cap'n Proto file / message
you must already know what data is in it (the schema).
Some see this as an advantage, because it forces you to write a
schema for your data structure, and you get slightly faster
encoding / decoding time.
And others see this is a disadvantage because you now have to
import schemas, or generate code, in order to read a serialized
message. You cannot just step through it like you can with e.g.
XML or JSON. I tend to be in this camp - although I am not blind
to the arguments in favor of external schemas. Speed matters, but
so does ease-of-use.
On a network protocol level I tend to disagree with the
"distributed object" model. I know Capn Proto tries to explain
why this model is not a problem with CP. However, fine grained
communication between fine grained distributed objects *is* a
performance killer in the long run, regardless of whether you
ION is intended to be the message format for our IAP network
protocol. IAP will be message oriented, so you can do one-way
messaging, request-response, subscriptions (e.g. to a stream),
pipelining, routing of messages via intermediate nodes etc.
Anyways, if you really want to use Cap'N Proto (or something
else) over IAP (+ION) you can just nest a binary message inside
an IAP message, and then parse it any way you like when it comes