brad at danga.com
Tue Feb 28 23:13:08 UTC 2006
The commands ("set") can be assumed to be ASCII, but the keys for the data
can be almost whatever. Few restrictions, but basically a char.
This is my biggest beef with C# and Java: always wanting you to work in
Strings with encodings. Usually it helps but when it doesn't, major
On Tue, 28 Feb 2006, Kevin Williams wrote:
> OK, that makes sense for storing the data. What about parsing the
commands? The protocol spec doesn't seem to specify any specific
encoding to use. I've browsed through some client implementations -
the Java and C# stuff use UTF8, the Ruby and Perl don't seem to
specify. I guess I'll use UTF8 for everything but the actual data,
keeping that as a byte.
On 2/28/06, Martin Atkins <mart at degeneration.co.uk> wrote:
> Kevin Williams wrote:
> > So if .NET defaults to UTF8 encoding on everything, the server
> > messages would be OK because ASCII characters encoded as UTF8 don't
> > change, correct? I'm trying to write a *server*, not a client, so I
> > just want to make sure that I do the right things internally.
> > Thanks for the help! I can't wait to get this running.
> The correct data type for storing data submitted from memcached clients
> is byte, not string. If you try to encode each byte as a Unicode
> codepoint in UTF-8 you'll end up with bloaty data every time a client
> wants to store a byte greater than 127.
> Different client libraries send different things, so all you can do is
> store it as raw bytes and serve it back exactly as it came, octet for
> octet; it's up to the client to know what format the data is in.
"Picking fights with people smarter than you
is great - you always end up learning something."
More information about the memcached