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
