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
