On Fri, Dec 28, 2012 at 8:59 AM, Stack <st...@duboce.net> wrote: > On Fri, Dec 28, 2012 at 1:31 AM, Devaraj Das <d...@hortonworks.com> wrote: > > > 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.. > > > > > Yes. Protobufs gives us wiggle-room. > > > > > 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. > > > > > This is how a client would learn of completely new functionality that has > been added to the server? > > On client setup of proxy, as first request, instead of asking server for > the version of the protocol it is serving, instead it could ask the server > for the pb'd description of the protocol [1] and the client could look at > this to see if the server supported new functionality? > > The returned descriptor would be much fatter than a bitmap. > > Bitmap is fine as well if the PB'ed representation is too verbose.
> St.Ack > > 1. > > https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Descriptors.ServiceDescriptor >
