binary protocol incr/decr proof-of-concept

[Dustin Sallings]

	My proposal (and implementation) supports both.  If you want it to  
automatically create stuff for you, you just specify what the new  
value will be.  If you don't want it to generate values for you, it  
doesn't have to.

	Are there semantics you're looking for that aren't covered here?

On Jul 28, 2007, at 0:28, Earl Cahill wrote:

> While we're here, perhaps I am alone on this, or maybe it is just  
> the perl client, but I think incr and decr should do their thing  
> for new keys.  Currently, in my experience, they return undef for  
> new keys.  I checked in my code and act accordingly.
>
> Thoughts?
>
> Earl
>
> ----- Original Message ----
> From: Dustin Sallings <dustin at spy.net>
> To: Memcached list <memcached at lists.danga.com>
> Sent: Wednesday, July 25, 2007 11:36:22 PM
> Subject: binary protocol incr/decr proof-of-concept
>
>
>     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
>
>
>
>
> Be a better Globetrotter. Get better travel answers from someone  
> who knows.
> Yahoo! Answers - Check it out.

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070728/ab3fc726/attachment.htm