The proposed changes (also in the document [1]): 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. [1]: https://docs.google.com/document/d/1aIVZ8SD5dMZXHTCeEY9PoNAwyuUgG-UEjmd3zfs1PYM/edit Best, David On 4/2/19, Wes McKinney <wesmck...@gmail.com> wrote: > I think we can have a vote. Can you write a summary bulleted list of > the changes/additions in brief? > > Jacques, what do you think? > > On Tue, Apr 2, 2019 at 1:31 PM David Li <li.david...@gmail.com> wrote: >> >> Just wanted to circle back to this - I've gotten a lot of feedback on >> the linked document, and I appreciate all the suggestions. Discussion >> seems to have quieted down; is this ready for a vote (perhaps as >> individual format changes)? >> >> Thanks, >> David >> >> On 3/22/19, David Li <li.david...@gmail.com> wrote: >> > Sorry about that! It should be enabled now, let me know if it doesn't >> > work. >> > >> > Best, >> > David >> > >> > On 3/22/19, Antoine Pitrou <solip...@pitrou.net> wrote: >> >> >> >> I second this request. >> >> >> >> Regards >> >> >> >> Antoine. >> >> >> >> >> >> On Fri, 22 Mar 2019 15:26:26 -0700 >> >> Jacques Nadeau <jacq...@apache.org> wrote: >> >>> Hey David, thanks for sharing this. Can you add comment capability to >> >>> the >> >>> doc for reviewers? >> >>> >> >>> thanks, >> >>> Jacques >> >>> >> >>> >> >>> On Fri, Mar 22, 2019 at 1:29 PM David Li <li.david...@gmail.com> >> >>> wrote: >> >>> >> >>> > Hi all, >> >>> > >> >>> > To bring this back up again, we've started experimenting with >> >>> > Flight >> >>> > for real now, and have some proposals. Including the >> >>> > justifications, >> >>> > they're a little long, so I've put them on a linked Google doc: >> >>> > >> >>> > https://docs.google.com/document/d/1aIVZ8SD5dMZXHTCeEY9PoNAwyuUgG-UEjmd3zfs1PYM/edit?usp=sharing >> >>> > >> >>> > In short, these proposals try to add the minimal amount in the >> >>> > APIs/protocol to be "production-ready" based on what we've seen so >> >>> > far. Originally, I brought up the idea of adding "escape hatches" >> >>> > to >> >>> > get at the underlying RPC framework objects, but after taking a >> >>> > stab >> >>> > at this, it isn't feasible in Python, making it kind of pointless as >> >>> > a >> >>> > solution. I'd like to avoid making Flight into a full-on RPC >> >>> > framework >> >>> > in and of itself, with an eye for portability in the future. We'd >> >>> > be >> >>> > willing to work on implementations of all these to get the ball >> >>> > rolling. >> >>> > >> >>> > Many of these could be solved in the meantime with reasonable >> >>> > defaults >> >>> > - but I think inevitably users will need to tweak lower-level >> >>> > details >> >>> > as things hit production, and generally reasonable defaults won't >> >>> > apply in every case. >> >>> > >> >>> > Finally, thanks to all who have been reviewing/working on Flight so >> >>> > far, I'm quite excited to start using it for real. >> >>> > >> >>> > Best, >> >>> > David >> >>> > >> >>> >> >> >> >> >> >> >> >> >> > >
