On Thu, Mar 27, 2025 at 12:01 PM David Li <lidav...@apache.org> wrote:
> It's not clear to me why (4) doesn't work. Can you speak more about the > flow of requests here? Putting a ticket inside a FlightDescriptor makes me > think something more complicated is going on. > I made a mistake in my description of method 4, I meant FlightDescriptor rather than "ticket". I apologize. Method 4 would be the creation of a new FlightDescriptor that is of the CMD type, with the original FlightDescriptor along with the predicate information serialized in some format understandable to the server. While technically any of these methods could work, I'm trying to achieve a solution that could yield the most interoperability with other Flight servers. It seems that this may not be important as the existing ecosystem of Flight servers don't have consistency beyond the gRPC spec. Or there really isn't a public ecosystem to speak of? If there isn't really an ecosystem or a desire to foster one I'm happy to just make a decision, send some type of "Flight client protocol" version header so clients/servers can determine the choices made, and move forward with implementation. > Alternatively...just create your own gRPC service, and return whatever > payload you need. There's no need to bend Flight to do something it wasn't > designed to do, and apart from the Arrow/Protobuf/gRPC integrations in the > data-carrying methods, there's no secret sauce in Flight anyways. > There may not be a secret sauce but there is the ease of implementation/deployment of having everything in a single service. Being able to write a Flight server following the cookbooks in different languages is very beneficial. *It is great actually. * Operating multiple gRPC services in the same processes in Python doesn't seem to be possible due to how gRPC is wrapped by Arrow Flight. As an aside, could "Arrow Flight: The Good Parts" be summarized as: * DoGet, DoExchange, DoPut, and DoAction. * FlightDescriptor/FlightEndpoint are both reasonable types to use, but FlightInfo should be avoided. * Authentication is a call to DoAction and gRPC headers. Best, Rusty
