Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Handling protocol versions

Copy link to this message
Re: Handling protocol versions
On Fri, Dec 28, 2012 at 1:31 AM, Devaraj Das <[EMAIL PROTECTED]> 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.