Cross-client memcached compatibility

[dormando]

> Since trying to re-ignite this discussion I've meandered across other 
> problems with getting cross-platform clients working, the biggy for me 
> is implementations of the consistent hashing algorithm differ between 
> clients meaning the same key for different platforms can end up hashed 
> against different memcached nodes :(.  Still working on that one [I have 
> now got Enyim.Memcached (C#) and Spy.memcached (Java) working together 
> successfully for UTF8 strings, with a minor tweak to the C# code and 
> some custom code plugged into the Java client] *sigh*

That's something separate which hasn't been dealt with yet... Even 
brad's tried a few times to figure that out, and no one really seems to 
care. I get the feeling just picking one or two consistent hashing 
algorithms and documenting them will be good enough. but I kind of don't 
want to have that conversation at this point? The hashes should be 
easily extendable for all of the clients anyway, so if someone really 
wants to make one portable to another language binding it's easy (and 
free for everyone else past that point).


> JSON does seem to be a popular choice, but I'm not sure how well this 
> would work in practice, i.e. how do you differentiate between a byte 
> array and a character array, or do we just not care etc. etc. (perhaps 
> thats easy to solve and my knowledge is lacking, quite probably in fact 
> ;) )

Example :) It'd work for most of what people need though.

> I think Tomash' solution allows for the current defaults to continue to 
> work, and for an optional 'cross platformish' (de)serialiser to be 
> agreed amongst the client authors, however as far as I can tell there is 
> no official communication channel to support cross-talk between the 
> client authors other than this list (which fairly obviously is server 
> orientated :) )

Tomash' solution is more or less what I'm advocating here; the idea is 
simply to add another (standardized being a pre-req!) serialization 
flag, so the clients don't need to even think about launching a callback 
if the value has been natively serialized. So there'd be a standard 
compressed flag, native serialized flag, application serialized flag, 
then whatever else. This is more simply a "Defaults be defaults" 
addition to the overall idea, to make it easier on the client author 
(and end user) community to pick it up.

-Dormando