Hi, Just thought I'd mention a project for something similar one of my coworkers has been working on.
http://github.com/mlum/thrift It adds C to the thrift generator (and is based on a fork of thrift so could be included at some point), it also uses glib quite extensively (so might be denied inclusion because of that). Anyway, cthrift seems like an awesome alternative when you want the fastest implementation. I look forward to hearing about it's progress. -Anthony On Wed, Mar 10, 2010 at 12:05:07AM -0500, [email protected] wrote: > > > > Well, several reasons (BTW: these are all IMHO, and I'm willing to be > convinced otherwise). > > 1. Model incompatibility: near as I can > figure out, Thrift generates the serialization/deserialization calls, and > uses fat libraries to translate the calls into byte sequences and then to > transport them. Among other things, this permits users to select > Transports and Protocols dynamically. > By contrast, cthrift generates > code for fixed Protocol/Transport pairs. The initial pair is > Binary/Socket. This allows it to generate code that is higher performance, > but takes away the flexibility of dynamically selecting > Transport/Protocol > > 2. Dynamic vs. static allocation: In > Thrift, the model on the receive side appears to be that an object is > created and handed back to the user. This is contrary to my preference, > which is to provide an object to the RPC stub, which is then filled in. > For instance, assume that you were reading a list of integers, which you > knew was never going to be more than a 1K long. The ideal situation would > be for you to pass in an int[1000] array to the RPC, which would fill in > the array. > cthrift provides for both models of memory handling: > passed in by the user and dynamically allocated by the RPC. > > 3. > Interface flexibility: Thrift starts with an IDL description, and > generates a unique RPC definition, possibly modified by annotations. > > cthrift recognizes that there may be several different interfaces > that map to the same RPC. As a trivial instance, consider sending a > struct. You may want to pass it in by value or by address, or perhaps > you'd like both functions to be available, so that you can pick the most > convenient one. cthrift will allow you to define both functions and map > them to the same RPC. > > > Hey, cool :) > > > > > Why not fold it into the main Thrift compiler, out of curiosity? > > > > > On Tue, Mar 9, 2010 at 10:34 PM, <[email protected]> > wrote: > >> > >> > >> > >> cthrift is > now alpha! > >> cthrift is a Thrift-compatible RPC stub > >> generator that starts from annotated C and generates fairly > efficient > >> client-side C code. See > http://cthrift.sourceforge.net for more > >> details. > >> Its definitely worth considering if you're using TBinary > >> over TSocket and: > >> 1. are running into run-time > performance issues > >> or > >> 2. you want to use C but > can't because Thrift doesn't have a C > >> generator > >> > >> > >> > > > > -- ------------------------------------------------------------------------ Anthony Molinaro <[email protected]>
