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
https://issues.apache.org/jira/browse/THRIFT-110
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 <[email protected]> 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
go
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
