binary protocol incr/decr proof-of-concept

[Brad Fitzpatrick]

We're supposed to be adding a binary protocol to the existing semantics
and not getting side-tracked on tweaking unrelated things.

If we really need some default value for incr/decr, let's do it later.  I
see no reason to do it now.


On Wed, 25 Jul 2007, Dustin Sallings wrote:

>
> 	I've done an implementation of incr and decr in my test server and
> client (and my real client) as I'd described earlier as a sort of
> proof-of-concept and it seems to work as I was hoping it would.
>
> 	It retains much of the properties of the original incr and decr
> implementations, but never treats the number as an ascii string.
> Because of this, I felt that it was important to be able to
> optionally pass a default value into the mutation command.  Since a
> value was needed, it also seemed important to pass the expiration for
> that value.
>
> 	Note that this does slightly conflict with the goal of keeping
> commands small and discrete since it may create a new mapping as a
> side-effect.  However, I think it makes things a bit easier.
>
> 	The request packet looks like this:
>
> [normal packet stuff]
> [32-bit unsigned incr/decr amount]
> [32-bit unsigned default value]
> [32-bit signed expiration value]
> [key]
>
> 	The response packet looks like this:
>
> [32-bit unsigned new value]
>
> 	If the expiration is less than 0, the default value is ignored and a
> NOT_FOUND status will be returned (as before).
>
> 	I had implemented mutation with default in my client by using a sort
> of complicated combinations of mutate and add.  I'm guessing other
> people either do the same thing (or worse, just a mutate or set).
>
> 	Note that flags are undefined here.  We talked briefly about having
> flags defined for common encoding mechanisms such as the big-endian
> 32-bit unsigned integer used in this response (as would be retrieved
> using a normal ``get'' command).  In the meantime, I've completely
> ignored the problem.
>
> 	Comments?
>
> --
> Dustin Sallings
>
>
>