Sounds fair. I am OK with putting down, permanent support of ApiVersion api versions, as a limitation in KIP.
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 > -- Regards, Ashish
