Could some other PMC members have a look at these proposals? 2 out of the 4 have the requisite 3 votes, while 2 need another +1
On Wed, Apr 3, 2019 at 10:44 AM Bryan Cutler <cutl...@gmail.com> wrote: > > +1 (non-binding) > > On Wed, Apr 3, 2019 at 7:52 AM Jacques Nadeau <jacq...@apache.org> wrote: > > > I'm +1 to all four (binding) > > > > On Wed, Apr 3, 2019 at 1:56 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > > > > > > > Le 03/04/2019 à 02:05, Wes McKinney a écrit : > > > > 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. > > > > > > +1 (binding). > > > > > > > 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). > > > > > > +0. > > > > > > > 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. > > > > > > +0. > > > > > > > Proposal 4: Construct the client/server using builders to allow > > > > configuration of transport-specific options and open the door for > > > > alternative transports. > > > > > > +1 (binding). > > > > > > Regards > > > > > > Antoine. > > > > >
