Hi, David Li has proposed to make the following additions or changes to the Flight gRPC service definition [1] and general design, as explained in greater detail in the linked Google Docs document [2]. Arrow Flight is an in-development messaging framework for creating services that can, among other things, send and receive the Arrow binary protocol without intermediate serialization.
The changes proposed are as follows: Proposal 1: In FlightData, add a bytes field for application-defined metadata. In DoPut, change the return type to be streaming, and add a bytes field to PutResult for application-defined metadata. Proposal 2: In client/server APIs, add a call options parameter to control timeouts and provide access to the identity of the authenticated peer (if any). Proposal 3: Add an interface to define authentication protocols on the client and server, using the existing Handshake endpoint and adding a protocol-defined, per-call token. Proposal 4: Construct the client/server using builders to allow configuration of transport-specific options and open the door for alternative transports. The actual changes will be made through subsequent pull requests that change Flight.proto and the existing Flight implementations in C++ and Java. Please vote whether to accept the changes. The vote will be open for at least 72 hours. [ ] +1 Accept these changes to the Flight protocol [ ] +0 [ ] -1 Do not accept the changes because... Thanks, Wes [1]: https://github.com/apache/arrow/blob/master/format/Flight.proto [2]: https://docs.google.com/document/d/1aIVZ8SD5dMZXHTCeEY9PoNAwyuUgG-UEjmd3zfs1PYM/edit
