Ciaran wrote: > It will not (native format is unpredictable, so you can't judge from > some first magic bytes), but I think this is not a problem. If the > goal would be to simultaneously support some clients that use only > native format, and some that use common, this would be no different > from requesting to support interaction with clients each using its own > format, and we are back to encoding used serialization method in > flags. > > If you want interaction among several clients, the requirement should > be to use the same serialization technique, no exceptions. If all > clients are from the same language family, you may use native, > otherwise you have to use common. > > I wholeheartedly agree :) > - Ciaran >
Well, for the second point, obviously? Yes? All I was proposing was a way to grandfather the current interfaces. Instead of forcing people into a new callback system if they decide to upgrade their client. For the first point; I don't understand why you'd want to arbitrarily limit serialization. If I write a gigantic web application which uses native serialization, and add a single experimental web service that pulls from a particular data stream, we should be afforded options. They don't even have to agree on anything other than "This ain't native, you ought to know better if you're asking for the key. But me, the client, certainly won't attempt to deserialize this for you". -Dormando
