On Apr 16, 2008, at 15:22, mike wrote:
On 4/16/08, Dustin Sallings <[EMAIL PROTECTED]> wrote:
* get (returns an object or error; does not return key)
* getq (returns an object; does not return missing; does not
return
key)
is the "q" something like "get quietly" ?
Yes, it's the quiet get we defined from the first meaning. It only
returns data, never returns anything on a miss (but could signal an
error).
* getk (returns an object with key or error)
* getkq (returns an object with key; does not return missing)
Do any of these return a "cache miss" message, or does it only return
if there is an error? If I read this right, "get" and "getk" both
return a miss...
That is correct. You do not get a cache miss message for q commands.
I could see client libraries benefitting from a "miss" message (for
all I know it could already be in the protocol though and my client
just doesn't do anything with it.)
Clients and servers benefit greatly from *not* having miss messages.
Imagine needing 1,000 keys for which only 100 are actually in the
server. You could issue 1,000 quiet gets and a noop (or 999 getq
commands and a get) and only have to deal with hits. The misses are
implied.
This is the same way the text protocol works today, except it's been
generalized slightly more and made a bit easier to deal with by not
having to have one command that takes an arbitrary number of variable
width keys that the server has to understand how to separate. All the
server wants to know is whether you want a response on a miss, and
(now) whether you want the key returned as well.
--
Dustin Sallings
