Hey James,
I think adding a separate capabilities endpoint is a good idea - it
doesn't need to be a bidirectional streaming endpoint which would
simplify implementation/usage and it would make it easier to maintain
backwards compatibility or slowly phase out handshake.
Best,
David
On 9/4/20, Jam
Are we concerned about backward compatibility with older FlightClients?
Would it make sense to continue to support handshakes with auth payloads
in addition to header-based authentication using middlewares? Perhaps we
create a dedicated endpoint for server capabilities if we need to remain
backward
The C++/Python authentication implementation is entirely different
(because the C++/Python/Java gRPC APIs are in turn entirely
different). In particular, gRPC middleware in C++ is still
experimental (compared to Java) and much more limited (unless recent
versions changed this). C++/Python might fun
Looking towards the future a bit, I don't see some of the facilities we
used for the Java code in the C++ Flight port.
Primarily the use of CallOptions -- I don't see existing functionality for
wrapping the gRPC stub within the context of
a single request. I do see that we pass in FlightCallOptions
Hey James,
I won't be able to attend tomorrow, but seeing as I've been commenting
so far - the changes as summarized in the presentation (+I think the
latest comments in the doc) look good to me, thanks for working
through the proposal with us.
Best,
David
On 9/1/20, James Duong wrote:
> Hi,
>
Hi,
I would like to talk about the changes in the design document and PR in
tomorrow's meeting.
I've created a slide deck to get the discussion going.
https://docs.google.com/presentation/d/1Bcvu0o0SEL21EMazA6O9fVfYZnzyvsQoKKBCN0NIdi0/edit?usp=drivesdk
Thanks!
On Wed, Aug 26, 2020, 13:12 James
