Wenbo Hu created ARROW-13889:
--------------------------------
Summary: Decouple Arrow Flight RPC from GRPC
Key: ARROW-13889
URL: https://issues.apache.org/jira/browse/ARROW-13889
Project: Apache Arrow
Issue Type: New Feature
Components: FlightRPC
Affects Versions: 5.0.0
Reporter: Wenbo Hu
I'm trying to implement Flight RPC on RPC framework with protobuf message
support in distributed system.
However, the flight rpc is tied to grpc.
Classes from grpc used in flight server are:
1. `grpc::ServerContext` used in grpc generated code in parameter, and used to
generate `ServerCallContext`.
2. `grpc::Status` used in grpc generated code as return type.
3. `grpc::ServerReaderWriter` and `grpc::ServerReader` used in massive wrapped
MessageReader/Writer classes.
1 & 2 are not coupled much with flight, while the third part is the tough work.
Shall we introduce an interface class with same semantics to allow anyone
implement the writing process to stream, such as
`arrow::flight::ServerReaderWriter` and `arrow::flight::ServerReader`.
So that, making a shim layer between `FlightServiceImpl` and `FlightServerBase`
is possible to decouple flight from grpc, meanwhile taking advantage of its
zero-copy messages.
All message converting processes can be handled in the shim layer.
For example, the function definition of `DoGet` can be `arrow::Status
DoGet(ServerCallContext* context, const pb::Ticket* request,
ServerWriter<pb::FlightData>* writer)`, which converts pb messages to flight's
and call functions from actual business logic implementation from
`FlightServerBase` as `Status DoGet(const ServerCallContext& context, const
Ticket& request, std::unique_ptr<FlightDataStream>* stream)`.
While, the client seems more complex, since the cookie stuff and others.
If the idea above is possible, I'll have a exploration on client in depth
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
