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
