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
