> 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.
Too much work I think. Variable length length fields are tempting, so maybe we could attempt an implementation and decide if it's too slow/annoying/etc. But if not I won't cry too hard. Can still save tons of bytes by flipping off features via flags. > My only argument is wanting more opcodes. :) ok. see below. > Yeah, that's the problem with packing the stuff tighter. You have to move > stuff around more to get alignment. If flags are turning 2 byte fields on/off, is something going to explode if CAS or bodylen just naturally ends up non-4-byte-aligned? I'm honestly dubious that this matters hugely. > It didn't look like opaque was required for quiet commands in ASCII. I > think that's the big difference. Is that a formal requirement already in binprot? I don't think it is? > I was thinking about this afterwards and it really seems like a good > solution is to just have three magics: > > * Request Magic > * Response Magic > * Unsolicited Response Magic > > Then you can receive unsolicited responses at any point without having to > worry about confusing it with normal responses. Does this makes sense? What's the difference between: - response packet with an unsolicited response - response packet with a flag and an unsolicited response ? Would a response packet have an expected opcode, but not be in response to anything you've done? Or would unsolicited responses be made up of specialized opcodes? If you move the quiet flag back into the magic byte, there're no more bits for an unsolicated response flag without dropping a second entire byte for flags.
