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: [email protected]
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 <[email protected]>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" <[email protected]>
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 <[email protected]> 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?
> >
>
