I'm glad you had a good experience with Protocol Buffers. (I work on the protobuf team at Google). But I would advise a bit of caution. Writing a fully-compl

I'm glad you had a good experience with Protocol Buffers. (I work on the protobuf team at Google). But I would advise a bit of caution. Writing a fully-compliant protobuf implementation is trickier than it looks. I'd recommend running any new parser through the conformance tests; I created these to exercise some of the edge cases. https://github.com/google/protobuf/tree/master/conformance https://github.com/google/protobuf/tree/master/conformance Here are some of the quirks of protobuf: - non-repeated fields can occur multiple times on the wire -- the last value "wins". - you have to be able to handle unknown fields, including unknown groups that can be nested arbitrarily. - repeated numbers have two different wire formats (packed and non-packed), you have be able to handle both. - when serializing, all signed integers need to be sign- extended to 64 bits, to support interop between different integer types. - you have to bounds-check delimited fields to make sure they don't violate the bounds of submessages you are already in. I do think protobuf is a great technology overall. But it has some complexities too; I wouldn't want to oversell its simplicity and have people be unpleasantly surprised when they come across them later. :)