arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Cutler <cutl...@gmail.com>
Subject Re: [VOTE] Proposed changes to Arrow Flight protocol
Date Wed, 03 Apr 2019 15:37:20 GMT
+1 (non-binding)

On Wed, Apr 3, 2019 at 7:52 AM Jacques Nadeau <jacques@apache.org> wrote:

> I'm +1 to all four (binding)
>
> On Wed, Apr 3, 2019 at 1:56 AM Antoine Pitrou <antoine@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message