Thanks Dustin again, for your working Java ClientAPI ;) . Because of our solution has complex parts, several programs in several programming languages, SO I want they (programs, websites, tools, bots) talk the same language on the same channel. The common channel is memcache, and we use native format for values, the common language is STRING format, only string. All values we use to test are string. We do the seriallization (simple ini-like, XML or JSON, all encode in UTF-8) before put it to our MemcacheHelper to write to memcacheD.
@Dustin: I think you should left the seriallization jobs to whom want to use memcache. They have several systems, they need 'em talk together, so they know what the most suitable seriallization way to implement, NOT YOU. They (the wild wide world who use memcache) develop program (maybe big program) know how to serialize :D , don't worry. Thanks again. Memcache must operate well, fast, reliable and simple. Memcache is useful and famous because of that feature. Add more complex transparent general enterprise blah blah features will make memcache become something like "Enterprise General Object Storing and Messaging System" (or some names big-guys at MS, Sun, IBM can introduce). We love memcache, only. But, last but not least: I think all ClientAPI version (C Java .NET, PHP, Perl, ...) MUST understand (get and set and incr/decr) native data formats, at least 32bit int and string. I think we need it, and I'll waiting.
