binary protocol motivations

[dormando]

> You may encode not_found reply as 
> 
>     * Magic byte / version (different from req's magic byte/version,
>       to distinguish that it's a response for, say, protocol
>       analyzers)
>     * cmd byte (same as response it goes to)
>     * err code byte (NOT_FOUND)
> 
> 
> So you'll save 4 bytes on positive response and a cost of 3 bytes on
> negative responce.  With the hit rate > 43%, you'll have the saving.

I'll peanut gallery this; While I like the idea of shaving a few bytes, 
I don't believe that many will matter enough to be worth special-casing 
client code.

What I've been reading shows a good split between the binary protocol 
shaving off some IO, and vastly simplifying clients.

Going over it in my head several times since first reading the thread, 
and while we could shuffle the header around, I wouldn't want to write a 
client to deal with that crap. It's a good idea to have the length at 
the end, since it prevents people from special-casing the entire 
protocol (like, say, MySQL does).

-Dormando