This looks like it could solve a lot of problems. I will look into this in greater detail later; I would like to see whether this can be used as a web service.
If I can write my web service in C++ and call it in Javascript, that would be amazing.
Not to take away from thrift in any way but could you not do this already using any portable serialisation method? Json has c++ and JavaScript (de)serialisation implementations as does XML. Combined with a Rest-ful web service api surely it doesn't matter what the transport mechanism is?
I guess their focus was on speed. XML is pretty slow and verbose, and whilst JSON is better, it's not the best solution. MongoDB's BSON is quite cool though.
Web Services and the associated HTTP headers are relatively slow, but browsers can make them, so are kind of necessary.
JSON does not work well for binary data. BJSON tries to fix this, but in languages like C++ you will still have to deal with clumsy parser syntax when you deserialize your stuff. It's much more convenient to have native classes representing protocol objects in your language (protocol compiler generates them for you).
Actually, it's from the same guy who implemented protocol buffers when he was at google. He re-implemented a better protocol buffers for facebook and chose to call it Thrift.
I wouldn't say that Thrift is clearly better then Protobuf. It's more like they solve slightly different problems and make slightly different tradeoffs.
Evernote uses Thrift. It makes sense to use it or something similar over a plain-text format if you control the server and the client and send a lot of data back and forth. Evernote has gone farther than that, though, providing a public API for it:
If you are looking at Thrift, you should take a look at ZeroMQ too: http://www.zeromq.org
ZeroMQ provides only ways to send/receive messages over several transport mechanisms (sockets on steroids) and address them to specific clients. It does not define what is the content of the messages, so you can send JSON/BSON/Protocol Buffer or whatever you come up with.
I work with it every day and it is a pleasure every single day.
We use both thrift and protobuf, and my experience with both has been very positive. I feel that protobuf is more mature and has better performance for the most part, but thrift does provide built in RPC support, which protobuf doesn't.
I think if I wanted to implement RPC I'd use thrift again in a second, and if I was sure I wanted only message passing/serialization, I'd go with protobuf again.
The other main factor is language support - while they are both very good at this, they have slightly different support, and if native PHP support is important to you, Thrift is a better choice, as well as for a few other languages as well.
12 comments
[ 3.5 ms ] story [ 35.6 ms ] threadIf I can write my web service in C++ and call it in Javascript, that would be amazing.
Web Services and the associated HTTP headers are relatively slow, but browsers can make them, so are kind of necessary.
If you want to develop a web service in C++, you could check out the available web frameworks, like OKWS[1], CppCMS[2] or TreeFrog[3].
[1]: http://okws.org/doku.php?id=okws [2]: http://cppcms.sourceforge.net/wikipp/en/page/main [3]: http://www.treefrogframework.org/
http://www.evernote.com/about/developer/api/ref/
I work with it every day and it is a pleasure every single day.
I think if I wanted to implement RPC I'd use thrift again in a second, and if I was sure I wanted only message passing/serialization, I'd go with protobuf again.
The other main factor is language support - while they are both very good at this, they have slightly different support, and if native PHP support is important to you, Thrift is a better choice, as well as for a few other languages as well.