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
