On Mar 13, 2012, at 4:27 PM, Piscium wrote: > 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.
If you want to go cross-language, then Thrift serialization is definitely the better choice. > > 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. I thought so, but figured I should mention 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. I don't know anything about HDF5, but I have a LOT of experience with Thrift. It's easy and intuitive and fast, and it's not too hard to integrate into your build process. We use it many different ways, and I heartily recommend it. > > We will see what happens. Best of luck to you. - Rush
