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