Empty arrays are already used in MetadataRequest to retrieve all topics in the cluster, ApiVersion request will have the same standard semantics.
2016-04-05 19:01 GMT+02:00 Ewen Cheslack-Postava <e...@confluent.io>: > 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 >
