Aaron, can you go into what you see the QuerySession looking like? At some point I remember you talking about getting off thrift, is this new api implemented in thrift or a wrapper layer around it to allow shifting front thrift? On Sep 15, 2012 10:13 AM, "Andrew Avenoso" <[email protected]> wrote:
> As a user of the current thrift api, I really like the idea of > simplification by having three separate apis. The majority of developers > will only ever need to use the client(controller) api. > > In order to solve the one shard problem, I think having the shard able to > respond to the controller api is a great idea. > On Sep 14, 2012 9:56 AM, "Aaron McCurry" <[email protected]> wrote: > > > In recent weeks I have had several discussions with developers over the > > complexity of the RPC and how we need to make it easier to use. I agree, > > but I have struggling to come up with a way to make things easier to use > > while still having all the components necessary to allow all the > different > > functions to operate. > > > > To date the Blur shard server and the Blur controller server have shared > > the same Thrift service API, perhaps that should change. A lot of the > > extra pieces to the API have come from this fact. Basically the > > controllers needs to be able to pass different information to shard > servers > > than the clients need to pass to the Blur controllers. > > > > The change that I am proposing, split the API into the 3 services. > > > > - User / Client API (for the controller) > > - Shard Server API > > - Admin API > > > > One pro to this design is that changes to the internal API (Shard Server) > > could be changed and have less of an impact to the clients if any. > > > > The only drawback to this approach is that the controller has to be > > deployed, even for testing. Currently you can just deploy a single shard > > server and have the same features as a whole cluster. We could get > around > > this by allowing the controller API (and the admin API) to be run in the > > same process as the shard server so that the same small scale testing > could > > occur. This then begs the question, do we need separate controller > > processes? Should we allow for all 3 API types to always be in every > > process? or should we keep things the way they are? or should we just > > allow users to configure things they way they want? > > > > Aaron > > >
