Hi Mayan, I haven't had time to look at your cthrift stuff yet, but wanted to give my quick input:
For the vast majority of use cases where I've seen Thrift in use, the overhead of Thrift itself is little to none compared to the overhead of network latency and the operation on the other end of the connection. Of course performance is important, but winning performance at the expense of anything else (complexity, wire version compatibility, etc) is probably not on the top of anyone's lists. Like I said, I haven't looked at cthrift, but wanted to let you know where I think most users' priorities are. -Todd On Mon, Mar 15, 2010 at 9:25 AM, Mayan Moudgill <ma...@bestweb.net> wrote: > I'd appreciate some feedback from users about where they want improvements > in the Thrift model. This may help me focus where I want to go with cthrift. > > I've been thinking about where to go with cthrift. Clearly, at some point > soon, cthrift will be able to generate fairly efficient client-side code. > Thrift2c will allow use of Thrift IDL, or perhaps assist in the migration to > C based stub-specification. > > On the server side, I _think_ that the current approach of splitting a RPC > call into 3 actions: > 1. recieve the message > 2. call the RPC specified in the message > 3. transmit the RPC response, if any > combined with the ability to add queues between these actions should allow > for the implementation of almost any kind of server models. > > Clearly, one possible future direction is to implement multiple skeletons > for different kinds of servers, so that it becomes more cut-and-paste to > implement a server. The target would be to implement a epoll OR select based > multi-socket kind of server, possibly with the receive and transmit being > implemented as co-routines (or threads) that switch if blocked on a > part-message. > > Another possible direction is to have cthrift also generate the code to > export the stubs to Python/Java/etc. as built-in modules/JNI/etc. The flip > side, of course, would be to embed Python instead of extending it. Would > anyone have a preference? > > Hmmm... if followed through to its ultimate conclusion, we'll have the > ability to go from Thrift IDL to a particular language interface, either in > Thrift or in cthrift. The difference will be that in Thrift the generated > code will be native (i.e. Python for --gen python etc.) whilst in cthrift > the generated code will be in C with enough glue to allow calls from the > desired upper layer language. > > Another difference, of course, will be that in the case of cthrift, the > transport/protocol choices will be more hardwired than in Thrift. > > Another question: what be the second most important transport? Is it > TFileTransport? > > > -- Todd Lipcon Software Engineer, Cloudera
