No responsibility to compare thrift vs protocol Buffers

Recently, we need to save some structured data. The general idea is to select XML. Define a schema, and then find a neat XML library (think tinyxml/tinyxml ++ is quite good), even if the problem is solved. The topic on blogs over the past two days is protocol buffers released from Google, a data description language used to partially replace XML. Google is Google, and even if it is pushed out, it can make people look at it. In fact, protocol buffers is not a new concept, not to mention the traditional ASN.1. Ice is a bit similar. Facebook launched thrift a year ago. It should be said that the positioning is very close. It is also rumored that Protocol buffers was first popular in Google, and then Google's staff jumped to Facebook, so thrift came out ...... Haha, stop gossip and get down to the truth.

Advantages and disadvantages of observation
Thrift:
More widely supported languages: C ++, Java, Python, Ruby, CSHARP, Haskell, ocmal, Erlang, cocoa, PHP, Squeak (abnormal enough)
Protobuf
Currently, only C ++, Java, Python, and other languages are supported.

Thrift provides more functions:
Thrift provides a simple RPC architecture (in fact, it is not simple, block and nonblock all have .....)
Protobuf seems to be dedicated to doing its own thing, only providing serialization and deserialization functions.

Thrift supports multiple Protocol formats.
Thrift code implementation, with a dedicated tprotocol and tTransport abstraction, can work with each other to implement multiple protocols for easy integration of various transmission modes. At least currently, thrift can use JSON as the serialization protocol.
Protobuf seems to be at ease with only one protocol, and is determined to make the format ready. The input and output are also standard streams. this is not exactly the case. protobuf also provides the text_fromat function for debugging convenience, which is also supported in nonbinary format. It seems that the new protocol is still possible.

Thrift also provides C modules in many languages (performance, performance)
All pure language implementations of protobuf are now 5 to 10 times faster. Don't care .....

Thrift currently does not support Windows platforms. At least the Runtime Library and generated code in C ++ language cannot be used on Windows platforms. (This is a bit unacceptable. Is it so difficult to support windows, because modern technologies are so developed and monsters Boost ?)
Protobuf does not solve this problem. It provides Visual Studio project files and can be compiled smoothly on the Windows platform. (For more information, see the protobuf test case ).

The thrift C ++ Runtime Library does not currently work on Windows. this means that you'll be able to compile thritidl files to C ++/Java/Python/etc ., but you won't be able to compile and run the generated C ++ code under windows.
Thrift Wiki

Protobuf focuses on Language Expression and has made a lot of effort in storage efficiency. It is quite convenient to use protobuf to directly read and write data structures.
Thrift focuses on building scalable services with exaggerated languages. It features many Supported languages and provides a complete RPC service framework, allowing you to easily build services directly, you do not need to do too much other work.

When the data types are relatively fixed, thrift and protobuf are much more convenient than directly processing XML. No matter whether it is Dom or sax, it is not convenient to directly access the data structure.