Cross-client memcached compatibility

[Tomash Brechko]

On Fri, Feb 01, 2008 at 08:38:44 +0000, Ciaran wrote:
> > The first, existing, one would mean "native language". Ruby marshal,
> > perl Storable, PHP ... whatever the hell.
> > Second would be 'application serialized', which it'd then run a client
> > callback as Tomash suggested. The client callback can use entirely its
> > own scheme to serialize/deserialize the structures (run it through
> > thrift, json, whatever).
> 
> I guess Tomash' point is  (to put words in his mouth perhaps against his
> will ;) ) that there is no actual need to do anything other than agree on
> the value of the 'serialisation' flag and not abuse it anywhere, then
> encourage the client authors to provide (de)serialisation hooks

Yes, I don't see the need to make native language case special further
than making it the default for the named hooks.  Still, we may need to
introduce second "SERIALIZED" flag for the benefit of some clients.
Then the clients that used hooks and one bit in flags would use a mask
with two bits, both with equal meaning: call hooks.  But some other
clients will use only the new bit for this, and the old bit would mean
old behaviour, for instance, "look into flags for more type info".


-- 
   Tomash Brechko