I think for Fllight, it'd be good to work out some negotiation that can preserve compatibility with the existing protocol as well, e.g. by taking advantage of headers. For some methods, like DoGet, the data flow isn't bidirectional so negotiating via headers (or earlier in the request flow, such as in GetFlightInfo) might be the only way.
Best, David On 6/23/20, Micah Kornfield <emkornfi...@gmail.com> wrote: >> >> How would negotiation work? By exchanging a dummy Schema at the start? > > That isn't specified here. I imagine there could be a new structure > defined specifically for flight that makes use of the enum. > >> I put together a PR with a proposal on how to do this [1]. The PR adds a >> > new enum "Feature", and adds a list of Feature to the Schema object. >> What about using a single bitfield? Or do we think we'll be using more >> than 63 or 64 flags? > > Hopefully no more than 63 flags, I guess if we ever get beyond that we > would declare V2.0 :) > > A bit-field could work, but it is a little easier to mess-up (e.g. > endianness). I would lean towards a list of enums because I think it is > harder to mess up, and we don't need to guess at the number of values > necessary, but that is subjective, and I could go either way on this. > > Thanks, > Micah > > On Mon, Jun 22, 2020 at 3:02 AM Antoine Pitrou <anto...@python.org> wrote: > >> >> Le 20/06/2020 à 22:33, Micah Kornfield a écrit : >> > This can also potentially help standardize negotiations between >> > clients and servers for flight. >> >> How would negotiation work? By exchanging a dummy Schema at the start? >> >> > I put together a PR with a proposal on how to do this [1]. The PR adds >> > a >> > new enum "Feature", and adds a list of Feature to the Schema object. >> >> What about using a single bitfield? Or do we think we'll be using more >> than 63 or 64 flags? >> >> Regards >> >> Antoine. >> >
