server encoding

[Brad Fitzpatrick]

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
hassle.

- Brad


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.
>
>


--
Cheers,

Kevin

"Picking fights with people smarter than you
is great - you always end up learning something."
- jcooney.net