+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

Reply via email to