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

[Galder Zamarreno]

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