Notes from the fourth memcached hackathon of undetermined frequency

[Aaron Stone]

On Apr 16, 2008, at 11:14 AM, Trond Norbye wrote:
>
> On Apr 16, 2008, at 9:52 AM, Dustin Sallings wrote:
>>
>> 	Stats are ugly and required a lot of thought.  We tried to hold of  
>> on designing a mechanism as long as we could (Trond suggested we  
>> wait for, you know, someone to care), but in the end, we decided to  
>> do something like an implied multi-get since Dormando claims to  
>> care a lot.  Enough to implement it anyway.  :)
>>
>> 	A stats command is issued with a single string parameter, and the  
>> server returns multiple responses, each containing a key, and a  
>> string value.  A terminating packet indicates the server has  
>> nothing more to say.  [We didn't really talk about the details of  
>> this, but I'd recommend terminating with a stat with a 0 length key  
>> and 0 length value.]
>
> I was thinking of this on my drive home trying to figure out a  
> solution, and I was thinking that a better solution might be to  
> return an "xml" document (yes, I know you all are screaming now)..  
> But.. who is the main consumer for the stats command? well it is  
> some sort of a management agent. Most languages contains libraries  
> to parse xml-documents, so it should be easy for them to "suck out"  
> the data they need (and it's not that much overhead to create it)..
>
> XML is a verbose format, but if we return a single "packet" pr stat- 
> item we add a 24 byte header for each item so I don't know if we  
> actually save anything by using single packets over the tag-overhead  
> in xml...
>
> Well, that's just an idea. (I think it will be easier to create a  
> management agent to use the data if it is encoded in XML with all  
> the XML libraries out there).. but then again, I didn't see the  
> point of creating the stats command before we had an actual use-case  
> for the command ;-)
>
> The other thing I remembered in the car was that the version-command  
> is not specified in the protocol. I sent a suggestion for it a time  
> ago to the mailing list.. any comments on that format, or should we  
> go ahead and use it?
>
> Too bad I didn't see Toru's suggestion, but I was so tired that I  
> had to drive home :( Anyway I had a great time last night, and it  
> was nice to meet all of you.

JSON is likewise very nice, and is a candidate for being recommended  
as a universal serialization / cross-language format -- if we do go  
ahead and define a baseline format all clients can assume will be  
supported, let's use it!

I think the hard part about STATS is not the packet the data is  
enclosed in, but rather _what_ data is returned and what it means!

Aaron