Two quick pieces of feedback: 1. The use of a version of -1 as magical entry dividing between deprecated versions is a bit hacky. What about instead having an array of supported versions and a separate array of deprecated versions. The deprecated versions would always be a subset of the supported versions. Or, alternately, since deprecation has no functional impact and is just a message to developers, we could just leave it out of the protocol and just have it in release notes etc. 2. I think including the api name may cause some problems. Currently the api key is the primary key that we keep consistent but we have actually evolved the english description of the apis as they have changed. The only use I can think of for the name would be if people used the logical name and tried to resolve the api key, but that would be wrong. Not sure if we actually need the english name, if there is a use case I guess we'll just have to be very clear that the name is just documentation and can change any time.
-Jay On Fri, Sep 25, 2015 at 2:53 PM, Magnus Edenhill <mag...@edenhill.se> wrote: > Good evening, > > KIP-35 was created to address current and future broker-client > compatibility. > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-35+-+Retrieving+protocol+version > > Summary: > * allow clients to retrieve the broker's protocol version > * make broker handle unknown protocol requests gracefully > > Feedback and comments welcome! > > Regards, > Magnus >
