We had previously talked about an even tighter binary protocol, but perhaps harder to generalize a parser around. This doesn't seem different enough from the existing binary protocol to warrant introducing an incompatibility.
Couple notes: * We can't omit the vbucket in the response if we're doing *K type operations (which I still don't think are necessary). * I like the idea of a separate quiet flag from the opcode (but will happily settle for having the bit in a consistent position) * Tap has a variable length extras, but we could possibly just push that into the body. * I don't quite understand the position of CAS in that diagram -- it looks like it's not aligned, but that doesn't sound right. * I like the ASCII stuff, but I would like to see more stuff around quiet that make it harder to get wrong. I'd like to re-propose all of the arguments I lost in the original binary protocol definition that have come back to suck for me and have another chance to lose, but with more experience now so I can actually say *where* it's sucked: * Untagged responses. * Signed incr (and no decr -- again) * Quiet as a flag. To expand: # Untagged Response Like IMAP, I'd like to have the ability to send messages from the server that are not responses to requests the client made. That is, messages can be sent *between* other messages. This allows for things like fully asynchronous responses interleaved with synchronous responses: 1> something that will take a while 1< doing 2> something quick 2< done 3> something else quick .< Hey, that thing from before is done 3< done Clients can ignore (or log or whatever) unsolicited messages they don't know how to handle, but some operations get *very* simple (observing internal memory restructuring, "jobs" over keys, persistence operations, proxy operations, etc...) # Signed Incr (and no decr) 5 + -1 = 4 One operation, one thing to worry about, one thing to test. We've had bugs in each of them separately. Counters aren't likely to actually go up above 2^63 (though I have had people say they slice a single counter up into multiple smaller counters and address the individual parts, so there's at least one reason, though, you know, bah). # Quiet as a Flag Again, happy to take it as a consistent bit, but it's not a different command, just different handling of the command both in the server and the client.
