Hi Daniel, Yes, so if you do end up going with HTTP, you can safely blow away all of the Thrift classes you're getting compile errors on. I believe it's just some sockets-specific code that doesn't compile against the device. There are also a lot of places where you need to remove the #import <Cocoa/Cocoa.h> line.
Regarding HTTP in C#, Fredrik Hedberg posted a patch a while back that adds a THttpHandler to the C# library. It's pretty easy to use. Patch: http://issues.apache.org/jira/browse/THRIFT-322 Just create some .ashx page that extends from THttpHandler and looks something like this: public class MyThriftApi : THttpHandler { public MyThriftApi() : base(new MyThriftService.Processor(this), new TBinaryProtocol.Factory(true, true)) { } } And, just for posterity, you can do the same with with Rails. Just add an action to a controller that looks like: def thrift buffer = StringIO.new transport = Thrift::IOStreamTransport.new StringIO.new(request.raw_post), buffer processor = MyThriftService::Processor.new(SomeImplementation.new) protocol_factory = Thrift::BinaryProtocolFactory.new() protocol = protocol_factory.get_protocol transport processor.process protocol, protocol send_data buffer.string end Best, Fred On Wed, Jul 8, 2009 at 8:45 AM, Dave Engberg <[email protected]> wrote: > > A basic HTTP server implementation is relatively simple. We implemented our > initial Java servlet in a few hours, although the code became much more > complicated later to add logging, security, etc. > > You need to implement a handler on the server to receive a binary POST. You > use the entire body of the POST as input to a TBinaryProtocol. The output > TBinaryProtocol should go into a byte array buffer, and these can be given to > the TProcessor for your service class. > > When the method call is done, you need to return the output byte array in the > HTTP response, along with the appropriate headers for Content-Length, > Content-Type, etc. > > Your HTTP server container should take care of most of the ugly details of > keep-alive, connection timeouts, etc. > > > > [email protected] wrote: >> >> At the moment there seems not tob e an implementation of the Http protocol >> for C#. I want to access a C# Server from the iPhone. Seems like a strange >> combination but should be trivial with thrift - right? But it seems that >> each side has its problems so I have to find a proper solution now. Seems >> that the binary protocol is the only way to do that at the moment if I can >> somehow overcome the iPhone compilation problem. Anyone else having >> experience with using thrift with the iPhone sdk? >> >> Mit freundlichen Grüßen >> >> Daniel Kreuzhofer >> Software Development Consultant >> >> Eugen-Roth-Weg 8 >> 85551 Kirchheim >> [email protected] >> http://www.kreuzhofer.de Mobil: 0160-94914133 >> >> -----Original Message----- >> From: Fred Potter [mailto:[email protected]] Sent: Tuesday, July 07, 2009 >> 10:25 AM >> To: [email protected] >> Subject: Re: iPhone SDK compiling issues >> >> Hey Daniel, >> Are you using TSocketClient or THttpClient as your transport? I know >> TSocketClient throws compile warnings as-is, but since I use HTTP for >> transport, I just blew away that class and moved on. >> >> Here's someone over on StackOverflow talking about the specific issue and >> solutions if you want to fix it: >> http://stackoverflow.com/questions/806116/is-there-anything-like-getstreamstohost-on-real-iphone-device >> >> Best, >> Fred >> >> On Tue, Jul 7, 2009 at 12:51 AM, [email protected] >> <[email protected]>wrote: >> >> >>> >>> Hi, >>> >>> did anyone yet compile a client version of thrift with the iPhone SDK. I >>> tried but it only worked when compiling with the emulator SDK. As soon as I >>> switch to the device SDK the thrift library does not compile. Is there >>> anyone having a working example of using thrift on the iPhone? >>> >>> Regards >>> >>> Daniel >>>
