Alternative Binary Protocol idea for memcached.

[dormando]

Clint Webb wrote:
> I wasn't expecting such a quick reply.  Good point about allowing
> multiple protocols.  I might pull out some of my old code and see how
> easy it is to drop in.
> 

Cool :) I think we'd like to see how fast this ends up being, and how
well it's worked into a client.

I'll drop some caveats though:

- We discussed the original binary protocol primarily as a method of
simplifying the client, as well as being able to scale the number of
commands in the server without using an if/else tree anymore (turn it
into a switch/callback instead). So the goals were simplification, and
speed.

- We had a few ideas floating on making a "fully flexible" protocol but
decided due to the former requirements we'd have to land somewhere in
the middle.

The binary protocol as is does allow command packing, but the header got
kinda lengthy after the last hackathon.

So if you wanted to do a set, then add some tags, you'd still do
something like:

setcmd
tagcmd
tagcmd

... in a single packet from the client (if the key is short enough). The
binary protocol also implicitly allows something like noreply by simply
adding more tiny commands.

It'd be cool to have all three. I just hope you guys intend on
benchmarking the damn things so we know what to recommend to client
authors/users :) I care about theory far less than I care about shit
working.

-Dormando