On Wed, 19 Oct 2011, dormando wrote:
> > I don't have the notes from that discussion, but there was the dream of > > the "five byte get" > > > > A byte of magic, a byte of flags describing the parts, a byte of opcode, > > and a byte of key length, then a key, "a" > > > > The flags would include things like quiet, CAS?, keylenlen, etc... > > > > It's harder to work with, but really tight. Double responding again... V3 binprot proposal does: A magic flag byte, opcode byte, 2 bytes of key length, then "a". so, five bytes. Another thing I'd like to float is that we do sorta lose the ability to version protocols if I shove the flags into the magic byte :( Another forceful tradeoff I was thinking about: 1 magic flag byte (req, res, and a 3rd magic for "unsolicited v3 res?"), 1 flag byte, 1 opcode flag, 1 byte keylen. Keylen has *never* been longer than 250 bytes. I win every argument against huge keys by pointing out that it's more efficient to sha1 long keys in the client than it is to send and store them. Long keys sets the bar so low that you trip over it. Given the max key length is 250, we *could* at some point rev the version again, and enable variable length encoding. Ideally keeping it simpler for now, and has the same 4 byte minimum as the V3 proposal. Does feel like a waste of magic bits, but perhaps future-proofing is a better idea. :/
