Two binary protocol questions (draft, stats)

Aaron Stone aaron at serendipity.cx
Thu Apr 3 19:19:07 UTC 2008


On Apr 3, 2008, at 11:51 AM, dormando wrote:
> Hey,
>
> - When I updated t/binary.t I only used the binary v2 document.  
> Somehow I missed a number of inconsistencies (I found a few!) that  
> Todd has now pointed out. There're more.
>
> We've adjusted the implementation to match the draft for the RES  
> magic byte, but at this point do we update the rest of the draft to  
> match the implementation, or the server to match the draft? This  
> would start with Todd's patches, then finishing up with everything  
> else.
>
> Some basics, like the remaining bytes disagree with the draft.  
> Obviously it's less work to just update the draft, but are we  
> missing features/intentions? I haven't had time to look, hoping  
> Dustin knows :)


Let's document the inconsistencies, and then make decisions about  
whether to change the code or change the docs based on that.


>
> - As far as completing the commands for the binary protocol goes, it  
> looks like we're just lacking the stats commands.
>
> I'd like to open the floor to ideas. I know trond's going to submit  
> one later on, but I'm curious if anyone's really thought about this  
> yet.
>
> The issue with the stats commands is about how we will agree to  
> format the responses in binary mode vs text mode. The simplest  
> obvious method is to just encapsulate the text responses in a format  
> similar to a get response.
>
> Otherwise we'll have to build a (hopefully very simple!)  
> alternative, then the actual implementation of the stats commands  
> will need to change to account for whom they're answering.
>
> If we make the format too complicated, we could end up with more  
> client code to *decode* the stats commands than for the rest of  
> them, so please keep that in mind :)
>
> -Dormando


Would it make sense to have a client API command similar to FTP's  
"quot" which passes an unknown client command to the server? Would  
this provide a reasonable mechanism for vendor extensions? (Or it  
might be a total mess. I'm still thinking.)

In any event, I think the stats key = value plain text response is  
completely reasonable.

Aaron




More information about the memcached mailing list