Any independent byte (... octet) that looks like a space will be treated
as a command token separator in the text protocol. In the binary
protocol it's just a length.
So if you have a utf8 character that's a valid non-space high byte for
the first byte, but the second byte is a space, it'd break. I'm not even
sure if that happens though.
We're trying not to promote people get into situations where their keys
will work with just one protocol or another, but we certainly can't stop
people...
-Dormando
Kieran Benton wrote:
No I don't think so :)
But it is very convenient to just have to not worry about falling foul
of not supported characters in keys. Its obviously an easy matter if you
are building a site that is for use with memcached from the start, but
if you are moving to memcached from another cache system (as I am) then
it is a bit of a worry if delimiters you have previously been using
might now be treated as erroneous.
Are we saying that as long as you use UTF-8 for the key, and that it is
not longer that 250 bytes, then all is fine with both text and binary
protocols? If so then I think we should update the docs to say so and be
happy :)
- Kieran
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dustin Sallings
Sent: 20 December 2007 17:58
To: a.
Cc: [email protected]
Subject: Re: What is a valid key?
On Dec 20, 2007, at 8:57, a. wrote:
I haven't seen the server from inside (I only wrote a client), so
maybe it's anoob question, but
why do we have to treat the key as a "string"? Cannot be just
treated as an array of bytes (whihc cannot contain some values
listed earlier)? So we do not have to care about codepages and
encodings and such?
You could do that in the server using the binary protocol, but
the
text protocol wouldn't be able to deal with it. It'd be good to
remain limited to the lowest common denominator.
I don't think anyone *really* cares about being able to use a
jpeg as
a key.
