Doug Cutting wrote: > Requiring servers to copy the call-id to responses > is an incompatible change. So is adding a magic number.
Do we want to introduce these incompatible changes in 1.3? If yes, I can file a JIRA and work on it. In 1.3 we can just introduce the simple (synchronous) client and server. Since the servers should anyway respect call-id, shall we also say that every request should have a call-id. The simple (synchronous) client may send the same id for every request. Since, with a synchronous client, there won't be more than one request outstanding at any given point in time, sending the same call-id is fine. This simplifies the protocol as there are no conditional elements in the request. This proposal makes the current client and server incompatible. Doug's original proposal makes only the server incompatible. What do you think? Thiru -----Original Message----- From: Doug Cutting [mailto:cutt...@apache.org] Sent: Wednesday, January 06, 2010 1:26 AM To: avro-dev@hadoop.apache.org Subject: Re: RPC multiplexing 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. > 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. Doug
