RE: Generating asynchronous interfaces for cocoa code

[Roger Meier <ro...@bufferoverflow.ch>]

Mike,
this is a great idea!

However, we have tons of open issues on cocoa lib and compiler.
https://issues.apache.org/jira/browse/THRIFT-1157?jql=project%20%3D%20THRIFT
%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20in%20(%22Cocoa%20
-%20Compiler%22%2C%20%22Cocoa%20-%20Library%22)%20ORDER%20BY%20priority%20DE
SC

some need review, rebase or patch creation
(http://wiki.apache.org/thrift/HowToContribute)

I guess there are some more people out there using Thrift cocoa library and
they would love better code and new features.

-roger
;-r

-----Original Message-----
From: Mike Riley [mailto:mikeriley@yelirekim.com] 
Sent: Donnerstag, 30. Januar 2014 23:36
To: dev@thrift.apache.org
Subject: Generating asynchronous interfaces for cocoa code

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