thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mayan Moudgill <>
Subject Re: heterogeneous collections
Date Mon, 03 May 2010 17:03:16 GMT

The idea of marshalling to strings seems somewhat counter-productive; 
after all, you're marshalling the data using Thrift, which then gets 
sent to a server, and demarshalls it. Now, on top of that you're adding 
another layer of marshalling.

A similar thing happens in  Cassandra (except that they use binary 
instead of strings), but at least at Cassandra the user-marshalled data 
is uninterpreted at the server - it only handles the data as an 
uninterpreted blob, so the marshalling/demarshalling is only confined to 
the client [I still wonder about how version control is managed - does 
everyone end up rolling their own?]

If, however, you're encoding the data for demarshalling at the server, 
it sounds like you want a different RPC framework. For instance, do you 
really need the version flexibility that is provided by Thrift? Are your 
types fixed at source & destination? Do you need a leaner transport? In 
fact, why did you pick Thrift in the first place?

Apropos the discussion on scalar/string compression in the
I'm curious: if a particular application would tend to compress better 
using a different algo than the one(s) provided, what happens?

> On Mon, May 3, 2010 at 7:09 AM, Bryan Duxbury <> wrote:
>>There is already a totally viable workaround, though - make a Union of the
>>types you want in your collection, and then make the field list<YourUnion>.
>>You get basically all the capabilities with very few drawbacks, plus the
>>ability to include multiple logical "types" in the collection, not just
>>physical types. Of course, if you literally need "any" possible object to
>>into the collection, then this won't do it for you.
> Thanks for the suggestion, Bryan.
> I'm experimenting with marshalling my values to strings (I only deal with
> basic types such as int32, int64, strings) right now.   If that doesn't
> work, I'll go with your suggestion.
> alex

View raw message