stats in binary protocol

[dormando]

Knew I was forgetting an important detail there :)

Toru; Putting the key in the response packet is what I meant, yes. So 
there's no encoding, except probably formatting everything (numbers, 
other strings) as strings in the value. This is, as you said, in 
alternative to encoding "<stat> = value" in the value part of the 
response packets.

I'll also echo Dustin's sentiments that the implementation is more up to 
you, I'm just echoing what we discussed prior, and Dustin's arguments 
below are more of the reason why multi-response looks to be the right way.

No strong opinions on returning an error or not on unmatched stats 
commands though.

-Dormando

> Well, as the one doing the implementation, I think you probably have a 
> bit more leverage at the moment to decide what's wrong.  :)
> 
> The general spirit of stats argument is that it's interpreted by the 
> server.  So we *could* decide that it's a good idea to have an argument 
> in the form of general:pid to return only the pid if it made sense.  The 
> only downside is that it'd have to be supported for a while.
> 
> Part of what we discussed was having the stats processed by multiple 
> parts of the server.  That is, there are stats that are core (such as 
> PID, rusage, number of hits and misses, etc...), stats that are 
> engine-specific (such as how many items total exist, LRU eviction stats, 
> etc...) and possibly others.  This means that a stats request has to be 
> passed around with a consistent API to emit values back to the client.
> 
> This is another reason the ``multi-response'' thing is necessary.  An 
> engine may have a *lot* of stats it wants to emit, and buffering that 
> all up and formatting it for a given protocol could be difficult and 
> would slow things down/use more memory.  It all just kind of works its 
> way out like this.  Formatting is handled by the protocol handler, and 
> content is handled by the thing that knows.
> 
> It is important at this point to determine what it means to provide an 
> argument the server doesn't understand (and what it means to not 
> understand it) in this case.  You could infer that if nobody emitted a 
> response, there was nothing interesting to say about it, or you could 
> have the API actually indicate whether or not the component actually 
> understood the stat argument.  Does it even matter?  We could also just 
> say, ``If the server has something to say about your argument, it will.''