I've used thrift in a few projects over the past three years and in each instance have ended up passing data from an iOS client back and forth from a server interface. Most of the implementations have ended up relying on [name your protocol] over HTTP. The problem I've found, is that our HTTP client for cocoa relies on NSURLConnection's synchronous transfer method, which while not inherently an evil proposition when used on a background thread, is really not an ideal way to be conducting network transfers.
My solution to this problem has been to write my own client side code which calls internal methods of the generated client interfaces and will first serialize the outgoing request, pass that raw data all at once to a custom transport (which does not jive with the provided system of auto protocol-transfer generation in cocoa libraries) then asynchronously decode that data using the matching method stub for whatever the method is. I can provide more details on how I'm doing this if anyone is immediately interested, but the implementation there isn't quite relevant to the reason I'm sending out this email. Does anyone feel like it would be useful to generate asynchronous interfaces for the objective C clients? I have had moderate success using the async methods in the java libraries on android clients but the entire process (requires a protocol factory and a separate class to "manage" the async bits) is really better described as "nonblocking" rather than "asynchronous". What I imagine most mobile developers want is something you can simply call which will "encode this stuff somewhere off of the main thread, send it to the network using a native system library, decode the response and spit the resulting object back out to me on the main thread". That process is the most straightforward way of handling client-server interaction, and for objective-c/ios, the best way of getting there easily is to generate the async interfaces as part of the code spit out from the compiler. I feel comfortable enough with thrift internals to handle making these changes myself, but rather than "shoot first and ask questions later", I'd like to collect any feedback or ideas about asynchronous implementation that the thrift dev team might have. Architectural ideas? How can I do this in a way that makes it as portable as possible to the existing relationships between protocols/transports/clients in thrift without complicating it too much? Thanks for your time. ~Mike
