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