Cross-client memcached compatibility

[dormando]

Tomash Brechko wrote:
> On Sun, Feb 03, 2008 at 15:59:31 +0300, Tomash Brechko wrote:
>> I see your and Aaron's point, agree, with my proposal it's impossible
>> to use two different serialization methods.
> 
> Just realized that there's a simple proof why you don't need a
> separate "native" flag for this purpose.  I'm not sure how this math
> method is called in English, when in order to prove something is
> false, you first assume that the proposition is true, and come to a
> contradiction.
> 
> Here it is: assume we have a separate "native" flag.  When client is
> somehow signalled to use native serialization (instead of the user
> hook), it executes "native" serializer, and rises "native" flag.  Now
> what if the client gets the data from the memcached with "native" flag
> set?  May it call native deserialization routine?  It's obvious that
> it may not do that in general case, because the data could be produced
> by the client for _another_ language in its "native" mode.  While
> deserialization will likely to fail in this case, there's a tiny but
> scary chance that it will succeed.  So it follows that if the
> application is designed correctly, in "native" mode it reads only the
> keys that are known to be produced in the same environment (with the
> same "native" serializer, likely by the same client).  But if we know
> that a particular key is native to our environment, then there's no
> point to have a separate "native" flag, single "serialized" flag means
> would tell everything.  EOD.
> 
> 
> If the user would want to use several serialization formats, she would
> have to use some prefix to encode the info on the used format.  And it
> seems it can't be made compatible with prefix-unaware clients.

Just to note that I'm not ignoring this. I have no constructive input
past this point :) Have you tried implementing any of this yet?

-Dormando