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. >
