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 Wed, 17 Apr 2013 18:54:25 GMT
To clarify what I meant about uploading an IDL file for Avinash, I'll try
to explain my totally impractical (but pretty nifty) Key Value store
service.

Thrift already has a system for taking a datatype as described by a
programmer and turning it into something you can generically communicate
between languages, that's the whole point of it! You just have to use IDL
files to describe your types, as we're all familiar with.  In our
hypothetical Key Value API, user's would write their own IDL files
containing the data types they want to use and then upload them to your
server, you would run the thrift compiler on these files, do a little post
processing of the generated sources, and then return to the user the method
signatures for calling to your API using their datatypes.

I didn't come up with this example because it's a good idea, I came up with
it because it is supposed to show you that you're re-implementing something
Thrift can already do, using Thrift.



On Fri, Apr 12, 2013 at 9:55 PM, Jens Geyer <jensgeyer@hotmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message