+1 (binding) In <cajpuwmbggi9k7ypoet9nnbsbuhvbm5kz3y7pnxvtq9kvz16...@mail.gmail.com> "[VOTE] Proposed changes to Arrow Flight protocol" on Tue, 2 Apr 2019 19:05:27 -0500, Wes McKinney <wesmck...@gmail.com> wrote:
> 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