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
