You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Wes McKinney <we...@gmail.com> on 2019/04/03 00:05:27 UTC
[VOTE] Proposed changes to Arrow Flight protocol
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: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Wes McKinney <we...@gmail.com>.
+1 (binding)
On Tue, Apr 2, 2019 at 7:05 PM 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
Posted by 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
>> >
>
[RESULT] [VOTE] Proposed changes to Arrow Flight protocol
Posted by 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: [VOTE] Proposed changes to Arrow Flight protocol
Posted by "Uwe L. Korn" <uw...@xhochy.com>.
+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: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Kouhei Sutou <ko...@clear-code.com>.
+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: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Wes McKinney <we...@gmail.com>.
hi,
We still need another PMC to look at the 4 proposals, since 2 of them
do not have the requisite votes.
Thanks
On Thu, Apr 4, 2019 at 1:28 PM Wes McKinney <we...@gmail.com> wrote:
>
> 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 <cu...@gmail.com> wrote:
> >
> > +1 (non-binding)
> >
> > On Wed, Apr 3, 2019 at 7:52 AM Jacques Nadeau <ja...@apache.org> wrote:
> >
> > > I'm +1 to all four (binding)
> > >
> > > On Wed, Apr 3, 2019 at 1:56 AM Antoine Pitrou <an...@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.
> > > >
> > >
Re: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Wes McKinney <we...@gmail.com>.
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 <cu...@gmail.com> wrote:
>
> +1 (non-binding)
>
> On Wed, Apr 3, 2019 at 7:52 AM Jacques Nadeau <ja...@apache.org> wrote:
>
> > I'm +1 to all four (binding)
> >
> > On Wed, Apr 3, 2019 at 1:56 AM Antoine Pitrou <an...@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.
> > >
> >
Re: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Bryan Cutler <cu...@gmail.com>.
+1 (non-binding)
On Wed, Apr 3, 2019 at 7:52 AM Jacques Nadeau <ja...@apache.org> wrote:
> I'm +1 to all four (binding)
>
> On Wed, Apr 3, 2019 at 1:56 AM Antoine Pitrou <an...@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.
> >
>
Re: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Jacques Nadeau <ja...@apache.org>.
I'm +1 to all four (binding)
On Wed, Apr 3, 2019 at 1:56 AM Antoine Pitrou <an...@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.
>
Re: [VOTE] Proposed changes to Arrow Flight protocol
Posted by Antoine Pitrou <an...@python.org>.
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.