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
