Notes from the fourth memcached hackathon of
aaron at serendipity.cx
Wed Apr 16 18:20:28 UTC 2008
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!
More information about the memcached