thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Riley <mikeri...@yelirekim.com>
Subject Re: Generic Data types design
Date Fri, 12 Apr 2013 18:21:40 GMT
I'm not suggesting you do the following, there are clearly a lot of issues
that would come with it. However I'm just trying to make an analogy to show
you how convoluted what you are doing is: you could just have users upload
an IDL file instead to achieve the same end, your service would then be
able to handle whatever kinds of data types your users wanted. You're
recreating the purpose thrift serves in IDL, the whole concept is confusing
and probably isn't going to help people readily adopt your api.
On Apr 12, 2013 12:05 AM, "Avinash Dongre" <dongre.avinash@gmail.com> wrote:

> Hi,
> 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
> api.
>
> Thanks
> Avinash
>
>
>
> On Fri, Apr 12, 2013 at 1:36 AM, Will Pierce <willp@nuclei.com> 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?
> >
>

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