I would be mostly interested in feedback by David Li and other Flight developers, otherwise it's fine to me.
Regards Antoine. Le 25/06/2020 à 05:12, Micah Kornfield a écrit : > 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. >>> >> >
