On Tue, Jan 5, 2010 at 11:56 AM, Doug Cutting <cutt...@apache.org> wrote:
> Philip Zeyliger wrote: > >> Thinking out loud, the handshake could negotiate not just the schema for >> the >> protocol, but also the schema for the RPC metadata. >> > > So we'd send a hash of the handshake's schema too? I think sending a magic > number is equivalent and simpler. A magic number implies a mapping between a magic number and a method of > reading the request off the wire. It seems that reading the request off the > wire is amenable to reading it with an AVRO schema, so we have a mapping > between magic numbers and AVRO schemas. > So the question is how we want to evolve RPCs. We can use untyped string->bytes maps, which is easy, but uses lots of strings. We can use AVRO itself, with its schema evolution properties, which means an extra "protocol handshake". Or we can use magic numbers, but we lose the evolution property. (We couldn't add "request_id" to the structure later, with an understanding that old servers would not respond with a request_id.) I'm in part playing devil's advocate here. Want to make sure we explore all avenues while we're changing stuff. > Is the call-id value arbitrary bytes? We wouldn't break compatibility >> with >> what's currently published if the server was allowed to not set call-id if >> it was responding to things in order. >> > > Yes, you're right. Requiring servers to copy the call-id to responses is > an incompatible change. So is adding a magic number. But the spec > currently does not yet define any transports, only request and response > messages, which do not change. So we can consider this requirement and the > addition of a magic number as a part of the specification of a TCP-based > transport and label the existing implementation non-conforming. > Sure. Not requiring the server to send back the id could save some bytes for servers that don't implement multi-plexing, but that's probably not worth it. -- Philip
