Hi Andrew,
I was hoping you were still around and would reply!
We want Cocoa client-side operations. Our server will be C++, so I
don't expect to get into too much unexplored territory.
I went ahead and made a Xcode project that builds a framework and a
Cocoa static library, but I haven't tried to use it yet. Once we have
tested our code against it, I will submit a patch.
What I did was this:
In lib/cocoa, I added a ThriftCocoa subdirectory that contains the
ThriftCocoa Xcode project. (The .xcodeproj bundle, info.plist, etc.)
The project has two targets. One called ThriftCocoa generates a Cocoa
framework. The other, called thriftcocoa_mt_s generates a Cocoa static
library that is called libthriftcocoa_dbg_mt_s.a in Debug and
libthriftcocoa_rel_mt_s.a in Release. (The "mt" stands for "multi-
threaded", and the "s" stands for "static".) This is our internal
naming convention, which allows static and dynamic libraries, as well
as both debug and release variants to be installed in the same
directory on OS X. Otherwise you get into problems with the default
linker behavior if you have static and dynamic libs in the same
directory. Both targets contain all of the source files in the tree
under lib/cocoa. So far, I have left the build settings with their
default values, so the build products get put in a build subdirectory
tree of lib/cocoa/ThriftCocoa. I'm going to need some way to install
the libaries and header files. I'll probably write a shell script for
now to get me through my testing. I don't know what's required for a
real patch submission.
One other thing on a slightly different subject. A colleague was
looking at the gen-cocoa code and made this comment:
"Because things like this:
- (NSArray *) queryActivation: (LsActivation *) proto : (NSString *)
queryStr;
Should actually be:
- (NSArray *) queryActivationWithPrototype: (LsActivation *) proto
andQuery: (NSString *) queryStr;
That is, each parameter gets a name in Cocoa."
How would you feel about a patch that changes the code generation in
this way? I think the real thing could generate something like this:
- (NSArray *) queryActivationWithProto: (LsActivation *) proto
andQueryStr: (NSString *) queryStr;
which would conform more to Cocoa conventions, but would change the
Thrift-generated classes for everyone. Maybe we could add a switch
that would turn on this style to the compiler command line args?
Thanks,
Rush
On Jun 19, 2008, at 6:56 PM, Andrew McGeachie wrote:
Hi Rush. I wrote the Thrift Cocoa library code and generators so
(hopefully) I can help you out.
The code in lib/cocoa/src is well suited for a framework but I never
got around to making one. Patches welcome, as they say. ;)
If you're going to be running a server in Cocoa one thing to keep in
mind is, well, that code's never really been used yet...
For a client, that stuff is in pretty good shape except for the
complete lack of comments. If you wanted to create a client using
the binary protocol on the HTTP transport you would start with
something like this:
// create a new thrfit HTTP client transport for each URL
THTTPClient * myTransport = [[THTTPClient alloc] initWithURL: [NSURL
URLWithString: @"http://myserver.example.com";]];
// create thrift binary protocol on top of transport
TBinaryProtocol * myProtocol = [[TBinaryProtocol alloc]
initWithTransport: myTransport];
// and lastly but not leastly, create actual thrift service client
on top of protocol
MyThriftServiceClient * client = [[MyThriftServiceClient alloc]
initWithProtocol: myProtocol];
[client doSomething];
Hope this helps.
- a
On Jun 19, 2008, at 3:37 PM, Rush Manbert wrote:
We have generated a Cocoa services interface and the objects it
uses. Now I'm trying to use them. How am I supposed to use the code
in lib/cocoa/src? It seems intended to be used to make a framework
or library, but there is neither Makefile nor Xcode project to
accomplish this.
Can anyone offer some guidance?
Thanks,
Rush
