On 2/13/13 4:08 PM, Jay Kreps wrote:
> Hey David,
> We ended up not versioning the response, instead the version must
> correspond to the request version.
> This makes sense from the client point of view. If you send a request
> using version X of the protocol you know you will get a response in
> format X. Separately versioning the response would seem to indicate
> that the server is allowed to send back a different version of the
> response. This means the client has to check this and handle old
> response versions (and what would it even do with newer versions?).
This makes complete sense. I was confused since OffsetCommit/Fetch are
including it in the responses
> Instead we thought it makes more sense to make the server deal with
> compatibility only. So the versioning is at the request/response pair
> and the server is required to always send the correct version of the
> response for all supported request versions.
> I just noticed that your responses for the offset apis actually have a
> version. We should probably remove that before the release.
> On Wed, Feb 13, 2013 at 12:48 PM, David Arthur <[EMAIL PROTECTED]> wrote:
>> Just noticed that most of the API response structs do not include the
>> ApiVersion. This will make it hard for clients to determine how to handle
>> responses once the APIs start getting updated (which is pretty much
>> I'd propose we update the standard response envelope to include it
>> Response => ApiVersion CorrelationId ResponseMessage
>> ApiVersion => int16
>> CorrelationId => int32
>> ResponseMessage => ...
>> Otherwise, it seems we must freeze the response formats forever.
>> Another thought is that the server should return the same version of the API
>> that was requested (if a client sends in v1, then presumably it does know
>> about any future versions...). How will this work? This seems to imply
>> backwards compat for the APIs like Avro.