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?
Don't clients hold on to the message id when a message is sent, and shouldn't the
response contain the same message id? That should allow clients to decide whether to
parse a return value or not.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache