Facebook's Cross-Language Network Library

koreth writes "Facebook has released Thrift, a toolkit for making remote method calls. It generates interoperable network code in C++, Java, PHP, Python, and Ruby. Its protocol is much more lightweight (and probably much higher-performance) than SOAP or CORBA. Facebook uses it internally for high-traffic services like search. The license is extremely permissive."

Perl?

[strredwolf]

Any ports to Perl? Anyone?

Indexes

[mwvdlee]

Why does the format include those "1:", "2:", etc. indexes in the structure definitions and method argument lists?
Couldn't it do this automatically, or can you mix them up in some way?

Re:Ohhh, goody

[Anonymous Coward]

http://www.zeroc.com/ice.html [zeroc.com] is supposed to be Corba well done. Have you tried it?

Re:Ohhh, goody

[Anonymous Coward]

The ICE website says "We have conducted extensive performance comparisons with TAO, which is widely considered to be among the fastest CORBA implementations available."
I wonder how much better it is - I had run extensive benchmarks comparing TAO releases to VisiBroker Java and VisiBroker/J consistently beat TAO by wide margins all times.

VisiBroker sure was a very neat CORBA ORB from Borland. May be I should go back and do some tests comparing VisiBroker and ICE.

Re:OT: A good C++ RPC library without code generat

[LizardKing]

Does anybody know any good C++ RPC library which uses templates and which does not need code generating with any external tool nor executable?

Yup, sockets. Every RPC-ish system I'm aware of (Sun RPC/XDR, CORBA, SOAP, RMI, ASN.1) needs a code generator that produces the stubs which make it easier than using raw sockets. The code that's produced by these stub compilers can be pretty small and well optimised (apart from SOAP), plus you shouldn't need to edit it by hand. Some compilers, such as a decent one for CORBAs IDL, can also produce the boilerplate code that you then fill in with your implementation of the RPC calls. While I usually dislike generated code, when it comes to RPC systems I'm quite glad they do a decent job of hiding complexity from me.

Pretty low level, but interesting

[kabdib]

Same ideas that have been around for 20+ years, but I have to admit it's a fairly nice implementation of a close-to-the-wire protocol.

They could have gone more flexible and abstract; structs are *bad* for you, and they're missing a fair amount of opportunity to make things dynamic, e.g., growable arrays, hashes, sets, arbitrary nested structures, and even things like canonicalized timestamps, which are a quite important (but often neglected) platform-dependent type (see how often time gets mangled when you go multi-platform...).

As for efficiency, it wouldn't be hard to be better than SOAP. I have some horror stories...

Re:Ohhh, goody

[sonofagunn]

CORBA is the best solution for a lot of applications. Web services just don't perform as well and don't handle more complicated interfaces as elegantly (inheritance, one-way calls, callbacks, etc).

Web services are nice for simple remote calls, but in a complex system where all sorts of RPCs are flying around the place, CORBA is a better solution.

Other solutions aren't as interoperable between different languages/environments. CORBA still has it's place. ICE sounds even better, but I haven't tried it. Given it's author, it should be very good. Thrift sounds similar, but I'd be much more trusting of ICE considering the source and maturity.