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 >
