Understood. The same problem you mentioned (inconsistent encoding
by not specifying a charset) applies to the key as well.
The problem that prompted this question, though is a bug where I
assume the length of the string is the same as the number of bytes
that will be in it on the wire. I'd always assumed keys to be ascii,
so that's true for all my use cases, but it's not true in general.
I asked this question to know whether to consider multibyte
characters an error or a valid use case. Sounds like it's valid, so
I'll make it work.
--
Dustin Sallings (mobile)
On Dec 20, 2007, at 8:42, "Rakesh Rajan" <[EMAIL PROTECTED]> wrote:
Dustin, just to clarify the bug report that I emailed you, the
problem was with the "value" and not the "key".
Since you bought up the key issue with UTF8, I think that it is
acceptable to force users to use ASCII as key, but allow values to
be UTF8.
-Rakesh
On Dec 20, 2007 9:15 AM, Steven Grimm <[EMAIL PROTECTED]> wrote:
On Dec 19, 2007, at 7:43 PM, Dustin Sallings wrote:
>> For the binary protocol I think none of this should matter at all.
>> A key has a key length, so the question of valid characters should
>> not be relevant.
>
> That's true, but it'd be really nice to not have different
rules
> based on protocol.
In particular, I think it's unacceptable to be able to set a key/value
pair with the binary protocol that you can't retrieve with the text
protocol.
-Steve
