thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avinash Dongre <dongre.avin...@gmail.com>
Subject Re: Generic Data types design
Date Fri, 12 Apr 2013 19:44:59 GMT
Can you please elaborate on " you could just have users upload
an IDL file instead to achieve the same end,"


On Fri, Apr 12, 2013 at 11:51 PM, Mike Riley <mikeriley@yelirekim.com>wrote:

> 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