[infinispan-dev] More thoughts on HotRod's ForceReturnPreviousValue

Hi all, I've been thinking further about ForceReturnPreviousValue flag in http://community.jboss.org/wiki/HotRodProtocol. Currently, if no ForceReturnPreviousValue is passed, the responses for put, putIfAbsent, replace, replaceIfUmodified, remove and removeIfUmodified looks like this: [header] Now, if ForceReturnPreviousValue is passed, the idea is this: If ForceReturnPreviousValue has been passed, responses will contain previous [value length][value] for that key. If the key does not exist or previous was null, value length would be 0. Otherwise, if no ForceReturnPreviousValue was sent, the response would be empty. However, as it is, this means that for a put, the response would be either, [header] or [header][value lenght][value]. So, in effect, the client decoder needs to know about the request itself to be able to determine whether it needs to read the value length or not. I wonder whether this could be imposing some restrictions on the client decoder. So, instead, I was wondering whether this might make more sense and make implementation of the client decoder easier. put, putIfAbsent, replace, replaceIfUmodified, remove and removeIfUmodified responses looks like this: [header][value length] *If no ForceReturnPreviousValue is sent, value length will always be 0*. If ForceReturnPreviousValue is passed and key was not present, or previous value was null, value length is 0. Otherwise, value length will be non zero and value will follow. The idea here is that these ops responses always return a value length, regardless of whether the flag is present or not. This, I think, would make client dcoders easier since they always know what they need to read and can pass it back without knowing which flags were passed on the request. Thoughts? -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache