Extensible command syntax

Dustin Sallings dustin at spy.net
Tue Nov 13 17:44:40 UTC 2007

On Nov 13, 2007, at 0:23 , Tomash Brechko wrote:

> You are failing to see my point.

	I do get your point, but I was just sort of indirectly arguing  
against it by use case since I think you're pointing to a limitation  
that I don't think affects anybody.  But as I'll try to explain below,  
I also don't see the limitation here at all.

> Yes, the result is always mapped,
> but such mapping may be a simple array or list of (key, value) pairs.
> Thus if we request keys in the array/list order and get the results in
> the array/list order, we only have to traverse this array/list and
> assign results in order.  This would make a simple client, and the
> only cost is NAKs in the wire (and they may be effectively compressed
> even if you want to optimize for "not found" case).  You don't need
> this in your Java framework, because you have to have dictionary
> anyway.  Still, other clients could benefit from that.

	The thing is, this *is* done, including the ``compressed NAK `not  
found' optimization'' you mention.

	In the text protocol, get results arrive in the same order (although  
the protocol documentation does not specifically state the order is  
preserved) as they are found in the request.  This includes duplicate  
requests for the same key.  However, only hit responses are included.   
The NAKs are *implied*.

	If I ask for [a, b, c, d], and I get back [c, d], then at the point  
where I got c, I know I'm not going to get a or b.  My client doesn't  
currently optimize for that case, but it certainly could if it  
mattered.  If I designed for an array of pairs, I could just as easily  
do the same thing.

	In the binary protocol, there is no multi-get, but there's the normal  
get, and a getq (no response is sent for a missing key).  I'd expect  
most people to use getq for batches, and the order must be retained  
because they're individual commands in sequence (my client doesn't  
maintain a map of outstanding commands, but rather a queue).  You'd be  
free to use get and get explicit NAKs if you wanted to, though.

Dustin Sallings

More information about the memcached mailing list