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
