[RESULT] [VOTE] Proposed changes to Arrow Flight protocol

[Wes McKinney <we...@gmail.com>]

The vote carries with 5 binding +1 for the 1st and 4th proposals, and
4 binding +1 for the 2nd and 3rd proposals

I look forward to the implementation of these features

On Sun, Apr 7, 2019 at 4:19 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>
> +1 (binding)
>
> On Sat, Apr 6, 2019, at 3:09 AM, Kouhei Sutou wrote:
> > +1 (binding)
> >
> > In <CA...@mail.gmail.com>
> >   "[VOTE] Proposed changes to Arrow Flight protocol" on Tue, 2 Apr 2019
> > 19:05:27 -0500,
> >   Wes McKinney <we...@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
> >

Re: [RESULT] [VOTE] Proposed changes to Arrow Flight protocol

[David Li <li...@gmail.com>]

Thanks again to everyone for the feedback! PRs will be incoming soon.

Best,
David

On 4/7/19, Wes McKinney <we...@gmail.com> wrote:
> The vote carries with 5 binding +1 for the 1st and 4th proposals, and
> 4 binding +1 for the 2nd and 3rd proposals
>
> I look forward to the implementation of these features
>
> On Sun, Apr 7, 2019 at 4:19 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>>
>> +1 (binding)
>>
>> On Sat, Apr 6, 2019, at 3:09 AM, Kouhei Sutou wrote:
>> > +1 (binding)
>> >
>> > In <CA...@mail.gmail.com>
>> >   "[VOTE] Proposed changes to Arrow Flight protocol" on Tue, 2 Apr 2019
>> > 19:05:27 -0500,
>> >   Wes McKinney <we...@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
>> >
>