On 13 March 2012 00:17, Rush Manbert <[email protected]> wrote: > 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...
Hi Rush, Thanks a lot for the helpful suggestions and information. STL: it's a possibility, though my thought is that using Thrift as an interface would make the visualization function easier to call from, let's say, Python, though this would be for the long term future. Security: again, for now this would be just a desktop application and the visualization function would not be available from the internet, so I am not much concerned about it. To conclude: I have not decided yet what to use, I will probably do a few more tests in order to make up my mind. Another library I considered is HDF5, which is normally used to store structured data in big files. Thrift has a range of options for transport layer, one of which is memory buffer. HDF5 likewise has a has a range of options for file type, one of which is memory file. One difference is that I don't think that HDF5 has a compiler, so that means a good deal of boilerplate code. I have no clue about how performance would compare. Although HDF5 is optimized for big files there are some settings that can be tweaked to have better performance for small files. We will see what happens.
