[PATCH] utf8 flag support on perl lib

Dustin Sallings dustin at spy.net
Sat Jan 12 20:25:57 UTC 2008

On Jan 11, 2008, at 6:07, Tomash Brechko wrote:

> Thinking more about this, perhaps we may do the following.  As I
> understand most client libraries do not export flags to the user, but
> use them internally for bookkeeping.  There are 16/32 (which one?)
> flag bits total.  We may separate this space into three classes:

	I thought the documentation had been updated for this.  It's been 32  
for a while now.

> 1 common, shared among all clients.  F_COMPRESSED goes here, and we
>   additionally agree that the compression algorithm is deflate
>   (gzip).
> 2 common to the language family.  F_STORABLE goes here got Perl
>   family.
> 3 common to the particular client family, i.e. private for internal
>   client use.  Please put F_UTF8 here ;).
> Class boundaries will be decided one and for all.  Class 1 will be
> maintained by memcached maintainers.  Class 2 will be maintained by
> the corresponding language community.  And class 3 is up to the client
> author.

	I don't understand why you wouldn't want UTF-8 in common.  It sounds  
like you're thinking really hard about a single client that supports  
UTF-8, but you think it shouldn't be there for all of them.

	In my client, I've broken the flags down into two sections:

	Actual flags (compressed and serialized) and specific types (integer,  
boolean, date, byte array, etc...).  The encoding is roughly identical  
for all of the special types, but the flag just indicates the values.

	I realize it's completely ridiculous to have serialized as a flag in  
this scenario.  I probably shouldn't do that, but efficient binary  
representations of specialized data types does seem like a good thing.

On Jan 11, 2008, at 23:01, Aaron Stone wrote:

> Just an FYI for this thread, in the binary protocol we have reserved
> some bytes for opaque flags. I think it would make a lot of sense if  
> the
> Perl client set a character string / binary string flag and used  
> that to
> do the right thing when retrieving the value.

	I really think this is a bad path to go down.  These are not visible  
in the text protocol.

	What do people use flags for currently other than to indicate data  
type?  I can think of a few things that one *could* do with the flags,  
but I'm curious if anyone actually does anything else.

On Jan 12, 2008, at 2:37, Tomash Brechko wrote:

> Besides, most clients do not agree on how to distribute keys among the
> servers, so there's more to it if we want to get smooth inter-
> operation.

	Is this true?  I was under the impression that CRC32 hashing with  
modulus bucketing was an LCD.

	This thread has a lot of ``but in perl, we don't care about these  
details of what bytes represent'' types of comments.  I don't think  
this helps with interop.  It sounds like you could just hard-code a  
set of flags and play along.

Dustin Sallings

More information about the memcached mailing list