On Mar 12, 2012, at 3:39 PM, Piscium wrote: > On 12 March 2012 17:16, Rush Manbert <r...@manbert.com> wrote: >> Of course you can use Thrift without using the RPC part. We do this in many >> different forms, mostly with custom protocols that we have derived from the >> binary protocol. >> >> The attachment contains a C++ file that uses the TFileTransport to write >> data into a file and then read it back. Note that it includes ThriftTest.h, >> which is generated from thriftSrcDistro/test/ThriftTest.thrift. >> >> If you use the JSON protocol (by commenting out line 20 that defines DENSE >> and uncommenting line 18 that defines JSON), you will get the data serilized >> as a string. The binary protocol also works. I'm not sure about the dense >> protocol. >> >> You can see that the basic method to serialize is to make a Thrift >> structure, then call its write() method, passing a protocol. >> >> I can't comment on the C support. Haven't tried it. > > Hi Rush, > > Thanks for taking the time to answer my query. In hindsight I should > have not mentioned the function SerializeToString as I really don't > know for sure what it does, and per your answer it probably does not > do what I thought it did. So I will now say a few words about what I > am trying to accomplish. > > I have a main program that gets data from a few places (example, > database), takes some user input, does some calculations and then > calls a visualization function to present the data to the user (or > print it, or save to file). The problem I face is how the main program > should pass the data to that function. Because the data is > heterogeneous and has a somewhat complicated structure I am exploring > the idea of the main program serializing the data, which will then be > deserialized by the function. > > There are several advantages to this approach: a clean interface > between the program and function that is documented in a readable > format in the .thrift file, and easier maintenance. Obviously there is > a cost in terms of serialization overhead, though my guess is that the > overhead would be less than 20% of the time taken to create the > display so I don't mind. > > Looking at Thrift, it seems that the best would be to use the binary > protocol. As for transport layer my _guess_ is that what I need is a > memory buffer. Do you know if such a memory buffer could be used for > my intended purpose, that is, pass data from the core of the program > to the function?
Hi Piscium, If we're talking about a homogeneous implementation, say all C++, then I would just use STL objects in the interface and not mess with serialization, because anything you can put together in the Thrift IDL you can just as easily define with STL. But if you want serialization, then you are on exactly the right track. Just use the binary protocol and the TMemoryBuffer transport, then pass the buffer to the callee and reconstitute it there. That works just fine, but can get a little unwieldy if you do it a lot. In your case, it sounds like a single call, so that should be easy and maintainable. I should probably also mention that the downside of doing this is that, without adding identity information, you are relying on the caller to be well behaved and not pass you a buffer that contains things you don't expect. Buffer overflow attacks come to mind... Best regards, Rush
