Reluctant development series (binary protocol)

[dormando]

Good news everyone!

http://danga.com/memcached/dist/memcached-1.3.0.tar.gz

We're having a development cycle!

The 1.3.x series of memcached will be a (I really hope) short series of
releases around the finalization of the binary protocol.

1.3.0 includes:

- A server implementation from Dustin Sallings
- Perl tests from hachi (and I helped!)
- Binary protocol specification drafts in doc/

There are also external python client/server from Dustin.

`make test` works. It doesn't seem to crash, although I haven't
extensively beaten it down yet. Looks good.

We're a little ways from GA. But not more than a few hours. Maybe a
dozen! Maybe two dozen. The short list for a 1.4.0 GA release:

- We _must_ have equivalence for all text mode commands.
  * All I know of that's lacking here are the stats commands, and maybe
flush with timeout? Any others we've missed?

- We _must_ have at least two more implemented clients in more
languages. It's easy to write under python, a little tricky under perl.
Are there any raw C gotchas? Ruby? Can pure PHP support it? Do we need
to modify the spec slightly to make it fit?

- We _must_ ensure the performance is at least equivalent to the text
protocol. The implementation now is a minimal subset of what was
required to make it work. We now need to ensure the binary
implementation batches syscalls for reads and writes as much as possible
to regain efficiency.

- We _should_ have the spec fully updated. It's a little out of date
now, but this is five minutes of work for Aaron I think.

- We _should_ ensure the code is as well organized and readable as is
reasonable. We have tons of tests, so it should be trivial to reorganize
the code a little once everything else is working.

- We _should_ settle the autonegotiation issue. Honestly I hate it, and
we might have a tough time making it fast. I'd recommend dropping it at
this point and leaving it up to the user to be more explicit. Unless, of
course, we get some really good argument otherwise. Which I'm totally
open to.

I don't like it adding implementation complexity, and encourages clients
to want to negotiate more details. Can you handle the binary protocol?
Do you support this binary-only feature? The user should be deciding
this tradeoff, especially if we take freedom with the new abilities of
the protocol.

That's it I think. Can we beat on this so we can do something else?

-Dormando