stats in binary protocol

[dormando]

Toru Maesaka wrote:
> Hi all,
> 
> So I've been working on implementing the stats command over binary
> protocol the last couple of days and came across few questions that I
> would like to ask. My approach is based on the discussion from the
> last hackathon. Heres a paragraph from Dustin's notes:

Thanks for doing this :) Sorry I suck. I'll comment, but Dustin/etc
should be able to comment on this as well :)

> (1) Since the server sends back each row of an arbitrary stats output
> at a time to the client, does this mean a given client should be able
> to ask for any specific information? (e.g. a client could _only_ ask
> for the pid of the server). This would make my life a little tricky
> ;-)

No, I believe the intent was that the key would provide sets of
information, not match specific information.

> (2) What should we do if a key wasn't contained in the request? I'm
> thinking that this case should be treated the same as "stats\r\n" in
> the ascii protocol. Is there any objections...?

Yeah. 'stats'.

> (3) What is the motivation behind sending row at a time?, when we
> could serialize the entire output of an arbitrary stats output and
> send it back to the client, like the current ascii approach (output
> data is fairly small afterall). I'm asking this since this approach
> would be relatively easy to pull off.

The idea was to make it simpler for the clients at a higher level. What
this does is allow the clients to return arrays of key/value responses
to their callers, instead of using some format that the client author
would then need to parse.

Presently it's a one-liner in perl to parse stats, the libmemcached API
"hates" the stats (but supports it, I think?), and designing it this way
would make it dead simple for all of the languages to return arrays or
hashmaps of the requested stats without any extra parsing code.

Of course, anyone's free to comment here :)

-Dormando