hi David, On the DoPut change, I am potentially in favor of making a change to support the use case you are describing. In principle, the CMD field of FlightDescriptor could be used to transmit application-defined information with a Put request. Though I suspect that a DoAction to "prepare" the server for a DoPut would be more common in production servers. I'm interested in Jacques's or others' thoughts about this
On the middleware API I am in favor; there are obviously a lot details that have to be worked out, but it's important that Flight servers and clients are able to be instrumented to collect metrics in a production setting. Thanks, Wes On Mon, Jul 8, 2019 at 9:33 AM David Li <li.david...@gmail.com> wrote: > > Hi all, > > I've put together two more proposals for Flight, motivated by projects > we've been working on. I'd appreciate any comments on the > design/reasoning; I'm already working on the implementation, alongside > some other improvements to Flight. > > The first is to modify the DoPut call to follow the same request > pattern as DoGet. This is a format change and would require a vote. > > https://docs.google.com/document/d/1hrwxNwPU1aOD_1ciRUOaGeUCyXYOmu6IxxCfY6Stj6w/edit?usp=sharing > > --- > > The second is to introduce a middleware API for Flight, to make > integration with logging and tracing frameworks (e.g. OpenTracing) > easier: > > https://docs.google.com/document/d/1Nm1ASp6w5PZQX42KkOTLK5LvrOv5q2cCbkaiVjqKjLU/edit?usp=sharing > > As part of this, I'm working on APIs to send richer error > codes/messages between Flight clients/servers, now that @Micah has > enabled custom error codes in Arrow-C++. These are API changes and > should not require a vote, I believe. > > --- > > Anyone should have comment access to these documents, but let me know if not. > > Thanks! > > Best, > David
