I think for now we just want to expose the gRPC impl under a different namespace
- FlightGrpcServer would expose FlightBindingService - FlightGrpcClient would expose FlightClient On Fri, Oct 4, 2019 at 11:48 AM David Li <li.david...@gmail.com> wrote: > Hi Rohit, > > This sounds interesting, and I think we've voiced support for > something similar before :) > > Given that Flight does want to abstract over the exact backends, > though, how should we approach this? Is the proposal to also refactor > Flight/Java such that the core classes are just interfaces (or > delegate to interfaces) that anyone can implement, and have the gRPC > implementation as the reference one? Or is this just proposing to > expose the gRPC implementation under a separate namespace, and leave > that question for later? > > Best, > David > > On 10/4/19, Rohit Gupta <ro...@dremio.com> wrote: > > Hi, > > > > At dremio we are using gRPC for JobsService. One of the api's relies on > > Arrow Flight. We want access to the Flight service so we can bind it to > the > > same managed channel as the rest of JobsService (& not have a completely > > separate server). > > > > The approach would be to create a new module within the same package > > (org.apache.arrow.flight) and have 2 classes FlightGrpcServer & > > FlightGrpcClient that expose the client & server, and also make > > FlightClient ctor package-private. > > > > Please let us know if you have questions or concerns. > > > > Best, > > Rohit > > >
