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
