thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer" <jensge...@hotmail.com>
Subject Re: Generic Data types design
Date Sat, 13 Apr 2013 01:55:25 GMT
Avinash,

what he's trying to tell you: It looks as if you would re-invent the wheel. 
If you continue that way, you will most probably end up with an API that is 
hard to use, prone to error and less performant than it could be.

>  My product is Key-Value store .
> Which has api like put(Key,Value)

Mmmh. For a key/value store, there are quite a lot of "name" fields in the 
values. What are they for? Are these names part of the data? Could you 
provide an example, how a typical client would use the API?

> > 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.

Does that mean, you are using other RPC mechanisms besides Thrift and want 
to keep them? If yes, what exactly are you using?




-----Urspr√ľngliche Nachricht----- 
From: Avinash Dongre
Sent: Friday, April 12, 2013 9:44 PM
To: user@thrift.apache.org
Subject: Re: Generic Data types design

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
View raw message