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
>>
>>
>>
>
