thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avinash Dongre <>
Subject Re: Generic Data types design
Date Fri, 12 Apr 2013 06:04:42 GMT
Thanks for your comments.
My product is Key-Value store . Which has api like put(Key,Value)
We have done all sort of stuff to make sure that we can handle C#, C++ and
Java object directly. What I was thinking to make it work with thrift.
So that If I am python developer, I can put my python objects using the put


On Fri, Apr 12, 2013 at 1:36 AM, Will Pierce <> wrote:

> I don't know anything about your API but in my personal experience, I tend
> to prefer APIs where every element is well-named and meaningful.  It
> provides a stronger contract from server to client about the commitment (or
> contract) to provide data in a certain way.  I most enjoy APIs that have
> strong internal-consistency for naming conventions and defaults, and also a
> lot of self-similarity so the outputs of one method are easily used as
> inputs to another.
> You can define all sorts of generic container objects that will cover every
> expected use-case, but you might want to think about the relative
> importance of flexibility vs. clarity of structure and simplicity, always
> remembering that flexibility is more expensive (for both sides of an RPC)
> in terms of code complexity needed to handle the various permutations in
> which a generic container type might manifest itself.
> I'm really guessing at your use-case here, though.    Can you share some
> more detail?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message