Cross-client memcached compatibility

[Tomash Brechko]

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.


-- 
   Tomash Brechko