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 > > >
