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
