Now thinking more about it, if a server implements a method more efficiently, we probably could have new fields in the method argument to indicate the client is willing to accept the new semantics. A new server could detect that (by checking for existence of such a field), and an old server would simply ignore that field. The new server could do a different processing of the request, and the response, although the same message type, might have new fields to capture the response under the new semantics.
Over time, the method code might evolve, and might become unmaintainable ... that's the worry. It might make sense to just break up the method into multiple implementations.. I am +1 for getting a PB'ed description of the protocol, the client caching it, and then deciding which method to invoke based on what's supported in the server. This will also address the orthogonal case of the server letting the client know all its capabilities. Thoughts? On Thu, Dec 27, 2012 at 7:11 PM, Stack <st...@duboce.net> wrote: > On Thu, Dec 27, 2012 at 5:37 PM, Enis Söztutar <enis....@gmail.com> wrote: > > > I think what Devaraj describes is a valid use case, and I am sure we will > > need it a few times. However, I suspect each of these might be unique, > and > > we have to deal with how to handle backwards-forwards compat from the > > client differently (image META moving to zk, after 0.96). So we cannot > > easily generalize, and we may still have to drop support for features > > gradually. > > > > > I agree. Just trying to make sure we have some facility in place to help > us over some of the humps. > > > > If we still keep the version, do we bump it every time a parameter is > added > > to a method, or only when a new method is added? It does not sound very > > maintainable. > > > > > Version alone won't work. > > The 0.94 branch might be version 100. > > The 0.96 branch might be 105. > > If we want to backport the method that cuts CO2 emissions by 25% but only > this method, what version do we give 0.94's protocol? We could make it 101 > but maybe 0.96.3 was 101? We could give it a version that has not been > seen before but then it gets a little awkward to manage and understand. > Regardless, client would have to keep a dictionary of methods per version > number, a pain. > > The suggestion above was that the server gives off a list of features > written in shorthand, a bitmap, where bits are set when a feature is added. > This way a client can look at the bitmap and see if the C02 saving feature > is available in the 0.94 server and if so, use that method. > > > > > 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. > > St.Ack > > 1. > > https://developers.google.com/protocol-buffers/docs/reference/java-generated#service >
