Null array sounds good to me as well. On Tue, Apr 5, 2016 at 10:06 AM, Ismael Juma <isma...@gmail.com> wrote:
> Yeah, we should use nullable arrays (which have been introduced in > KIP-4-Metadata) instead of empty list to indicate all versions. > > Ismael > On 5 Apr 2016 18:01, "Ewen Cheslack-Postava" <e...@confluent.io> wrote: > > > Also, just a thought but is empty list the sentinel we really want to > > indicate we want all API versions? We've got nullable string and nullable > > bytes in the protocol. Should we have nullable array support as well and > > use that to indicate we want everything? I can't think of a use case for > > sending an empty list, but null seems like a better sentinel than an > empty > > list. > > > > -Ewen > > > > On Tue, Apr 5, 2016 at 9:23 AM, Ewen Cheslack-Postava <e...@confluent.io > > > > wrote: > > > > > > > > > > > On Mon, Apr 4, 2016 at 11:24 AM, Gwen Shapira <g...@confluent.io> > wrote: > > > > > >> > > > >> > > > >> > In case of connection closures, the KIP recommends that clients > > >> should > > >> > use some other method of determining the apiRequest version to > use, > > >> > like, > > >> > probing. For instance, client will send V0 version of apiVersion > > >> request > > >> > and will try higher versions incrementally. In case b, client > will > > >> > eventually get apiVersion response and know what api versions it > > >> should > > >> > use. For case a and c, client will eventually give up and > propagate > > >> an > > >> > error to application. > > >> > > > >> > > > >> I strongly disagree that we should recommend this probing method. > > >> Probing is essentially what clients do now (since we lack any way to > > >> communicate versions), and is what we are trying to solve with this > KIP. > > >> Considering that different brokers could have different versions, and > > that > > >> brokers can change version at any point, this sounds slow, difficult > to > > >> implement and fragile. > > >> > > >> Also note that even with this method, without VersionRequest v0, we > will > > >> break clients in the one way Kafka currently promises to never break: > > Old > > >> clients won't be able to work with new brokers. > > >> > > >> If this is part of KIP-35, I am against it. > > >> > > >> Since all Request/Responses in our protocol have versions, publishing > > >> versions for each request/response should be something we can easily > > >> support into the future. It sounds far easier than asking every single > > >> client to implement the method you specified above. > > >> > > > > > > Gwen, > > > > > > Agreed, and I think it would be fine to make permanent support (barring > > > massive changes to the protocol) part of the KIP text. There's really > no > > > reason not to and it basically just turns this into the basis for a > > pretty > > > simple handshake protocol. > > > > > > (I'm tempted to not even bring this up given that we're converging, but > > > one reason I could see this being changed in the future is that > protocol > > > support is only conveyed in one direction. This could also be turned > > into a > > > slightly more general handshake approach where the client also > advertises > > > what it supports. However, given the way request/response versioning > > works, > > > I can't think of a reason we'd need this atm.) > > > > > > -Ewen > > > > > > > > >> > > >> Gwen > > >> > > > > > > > > > > > > -- > > > Thanks, > > > Ewen > > > > > > > > > > > -- > > Thanks, > > Ewen > > > -- Regards, Ashish
