| 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 json For 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 languages JSON -- 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) |