On Thu, Dec 27, 2012 at 7:11 PM, Stack <[email protected]> wrote: > Not knowing much about the recent changes, why don't we go full PB, and >> define actual rpc methods as services? (as in >> https://developers.google.com/protocol-buffers/docs/proto#services) >> >> > I thought about it. It has some nice facility that comes for free. For > example, you can get an aforementioned pb'd description of the "protocol" > and actually used the return to compose an invocation against the server. > Nice. Our 'protocols' actually already implement Service.Interface from > pb (actually Service.BlockingInterface). I'm not sure why as it looks to > complicate things going by a quick examination today (I started stripping > it out to see what would break). So it would not take too much to get a > Stub on clientside and have servers implement the Service. We could try > shoehorning our RPC so it implemented the necessary RpcController, etc. > Interfaces. > > But it would seem Service is deprecated with a good while now [1] and > folks are encouraged to do otherwise because as is, the generated code > makes for too much "indirection" [1]. > > I could try playing around some more w/ using Service to learn more about > this 'indirection'. We could use the long-hand service descriptor in place > of the above suggested bitmap figuring what the server provides. > > I experimented hooking up protobuf Service to our RPC. I put up a patch over on https://issues.apache.org/jira/browse/HBASE-6521 along w/ some notes made while messing.
The main 'pro' is that our rpc would get a much needed spring cleaning. Main 'con' is that we would be changing code (smile). The main TODO is making sure no performance degradation (should be none server-side, need to make sure same is true client-side). This experiment has made me change my opinion regards 'versioning'. Above I suggest we remove VersionedProtocol and add in instead a protobuf ProtocolDescriptor that would have a 'version' as well as a short and long form description of server 'features'. Now I think we should just punt on version/descriptors altogether. Lets just go the route where a method is supported or not. That methods take a protobuf request and returns a protobuf response, as has been said already, gives us some wriggle room to evolve methods as time goes by. For protocol migrations that require more this 'vocabulary', lets deal w/ them on a case by case basis (As per Enis above). St.Ack
