Experience with Protocol Buffers
joeld42: I've used this for some projects, with much success. In one case I used it as a data interchange format between a C++ app an some Python utilities. It worked very well for that and the generated API's were easy to work with, albiet a bit bulky.In another case, more of an experiment, I used them to serialize game data and sent it using enet. This proved very flexible and easy to change/add things, and the packets were extremely compact.Pros:* Read/Write access to data from C++ or Python* Generated API's were easy to work with* Very compact representation* Ascii-dump version very useful for debugging* More error checking than something like json (i.e. it tells you if you leave out a required field)Cons:* Adds some build steps, can be more of a headache to maintain (compared to json or something)* API can't parse ascii version, bad for config data or other stuff that might want to be human readable (vs. xml or json)* Generally requires copying your data into the protobuf struct, and then packing, rather than going straight from your "native" format into a packed buffer.* Adds a bit more complexity* Not as lightweight as jsonFor what you're doing, I would recommend them.They're great for "structure" style data, a little weird for array-style. For example, one of the things I was storing was a 4x4 matrix, and I resorted to making a struct with 16 members such as m_00, m_01, etc.. which worked fine and it stored it compactly but was a little weird. I don't think there's a way to have a float[16] or something like that. I could be wrong, maybe there's a better way to do this.Generally, these days i use one of three formats. I am very happy to have outgrown xml.protobuf -- for hierarchical, nested data, if it needs to be compact and accessed from different languagesJSON -- for quick and dirty stuff, when format needs to be flexible (or when i need to use javascript)GTO -- for large sets of structured data. (www.opengto.org)