Dustin, Dormando, Thanks for the feedback, you guys got rid of my concerns :)
> 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. Sounds good! >> 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 Gotcha. I will keep this in mind when I design the approach. Okay, so let me get back to you guys when I have something decent to show (though I assume we'll be chatting on IRC much sooner than that). Have a good weekend, Toru On Sat, Jun 28, 2008 at 3:08 AM, dormando <[EMAIL PROTECTED]> wrote: > 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.'' > >
