On Tue, Jul 31, 2012 at 1:47 AM, Devaraj Das <d...@hortonworks.com> wrote: > Wondering whether we should retain the VersionedProtocol now that we have > protobuf implementation for most (all?) of the protocols. I think we still > need the version checks and do them when we need to. Take this case: > 1. Protocol Foo has as one of the methods FooMethod(FooMethodRequest). > 2. Protocol Foo evolves over time, and the FooMethod(FooMethodRequest) now > has a better implementation called FooMethod_improved(FooMethodRequest). > 3. HBase installations have happened with both the protocol implementations. > 4. Clients should be able to talk to both old and new servers (and invoke the > newer implementation of FooMethod if the protocol implements it). > > (4) is possible when the getProtocolVersion is implemented by the protocol at > the server. The client could check what the version of the protocol was > (assuming VersionedProtocol semantics where the protocol version number is > upgraded for such significant changes) and depending on that invoke the > appropriate method... > > Having to map version-numbers of protocols to the methods-supported is > probably arcane IMO but works.. > > The other approach (that wouldn't require the version#) is to do something > like - On the client side, get the protocol methods supported at the server > (and cache it) and then look this map up whenever needed to decide which > method to invoke. > > Any thoughts on whether we should invest time in the second approach yet? >
The VersionedProtocol w/ client being able to interrogate what methods a server supports strikes me as a facility that will be rarely used if at all and bringing it along, keeping up the directory of supported methods, will take a load of work on our part that we'll do less than perfectly so should it ever be needed, it won't work because we let it go stale. What do you reckon? The above painted scenario too is a little on the exotic side. We can do something like Jimmy suggests in those rare cases we need to add a new method because there is insufficient wiggle-room w/i the particular PB method call (If we get into the issue Ted raises where we'd have to go back to the server twice because there is a third new method call, we're doing our API wrong). The protocol needs a version though. We'll be still sending that 'hrpc' long in the header preamble? Should we add a version long after the 'hrpc' long? As to a directory of supported methods, do we need this in the protocol at all? Can't this be knowledge kept outside of the on-the-wire back and forth? St.Ack
