I've updated the PR. More feedback welcome, I'd like to start a vote by end-of-week if possible.
On Wed, Jun 24, 2020 at 12:48 PM Micah Kornfield <emkornfi...@gmail.com> wrote: > I agree flight might need to encode this data slightly differently for > negotiation purposes. I will update the enum to use power of 2 values so > this isn't precluded, but I think for parsing in the schema, it is clearer > to model this as a list of enums. > > Any other thoughts? > > Thanks, > Micah > > > > On Tue, Jun 23, 2020 at 7:58 AM Wes McKinney <wesmck...@gmail.com> wrote: > >> I'm in favor of the list of enums myself -- it seems like it will be >> easier to work with and less error prone in general. Storage space >> with this should not be an issue. >> >> On Tue, Jun 23, 2020 at 7:31 AM Antoine Pitrou <anto...@python.org> >> wrote: >> > >> > >> > >> > Le 23/06/2020 à 06:02, Micah Kornfield a écrit : >> > >> >> > > A bit-field could work, but it is a little easier to mess-up (e.g. >> > > endianness). >> > >> > I don't think endianness can be an issue. A bitfield would have the >> > same representation as any "long" Flatbuffers field. >> > >> > > 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. >> > >> > The main concern is "make it easy to query features". For example, if >> > Flight wants to encode the features as a gRPC header, it's easier to do >> > if it's a single integer value (though the value is opaque). >> > >> > Regards >> > >> > Antoine. >> >
