On Monday, October 24, 2011 6:48:42 PM UTC-4, Dormando wrote: > > > There's nothing like that currently. Last discussion I remember is that > > we decided against allowing binary keys at the client because we don't > > know what other clients may expect when trying to get that item. > > > > We can certainly reconsider that, but it's not been needed thus far. > > What the hell? I thought 50% of the whole point of the binary protocol was > to make binary keys possible. It's a flag in most other clients. You know, > like, that whole utf8 argument? Are you absolutely sure about this? > There were strong arguments for keeping keys compatible with both ASCII and binary clients, to the point where it was decided to keep parity between the two.
We can certainly revisit that now, but I don't remember anyone advocating for arbitrary bytes in keys other than asking if we should and having someone else say we should keep the same constraints on both sides. (that's from memory, I don't remember who said what, but it made sense at the time) The client side checking predates the protocol implementations anyway. We can pull it from the clients and just wait for the server to send it back, but there are cases where it'll cause a lot of confusion in the ascii protocol at least since your key can otherwise look like a complete request.
