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?
