kevwil at gmail.com
Tue Feb 28 23:46:29 UTC 2006
Encoding usually doesn't get in my way, it's only needed when reading
text files, using serialization, or streams. I don't use those much on
a day-to-day basis, so when the issue comes up I'm like "Aaahh! Which
one do I use?". Still, I'm happy I have Strings - I guess that
explains why I never felt comfortable in C.
Thanks again! If I can get this running I know some Windows-addicted
guys who will be very happy.
On 2/28/06, Brad Fitzpatrick <brad at danga.com> wrote:
> 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
> - 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.
> "Picking fights with people smarter than you
> is great - you always end up learning something."
> - jcooney.net
"Picking fights with people smarter than you
is great - you always end up learning something."
More information about the memcached