Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com
 designates 209.85.214.53 as permitted sender)
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CAMUu0w9Q5c8mNZNeO-8cmnZJyTAOQxqs5vmS2mPyMWL-_WWwew@mail.gmail.com>
References: <F8F3F040-80E9-4737-96C0-1B285A1D3E53@hortonworks.com>
	<CADcMMgGV2x1K3k0G3qJr1NoFq-V8jx0uo12rBRAuYzui42FyRQ@mail.gmail.com>
	<CADY20s5qobOH99z-Z1hh8bJte2rgnBD3+WApt9tq3C7q9Y2f-w@mail.gmail.com>
	<CA+RK=_Dg0YS5VBbASAU2P2qvfZjkE+wVB4E1ogUnji6gqzCCQw@mail.gmail.com>
	<88EC303B-9769-4C3A-B3A7-450B468F6486@hortonworks.com>
	<CADcMMgFsxWsQcRst9HzKcf8ucexgmfb4nojaiEnXrziZ+CCbFQ@mail.gmail.com>
	<CAOmV22sgFsYHTLbBZjeY+AM5nYUeAqg=x_dcTO6G4VnAp7vWAw@mail.gmail.com>
	<CAMUu0w9Q5c8mNZNeO-8cmnZJyTAOQxqs5vmS2mPyMWL-_WWwew@mail.gmail.com>
Date: Thu, 27 Dec 2012 19:11:48 -0800
Message-ID: 
 <CADcMMgE7z0XNChoypSWR_=JoD353V_zm4c_Ood_xMHyxdVv4mQ@mail.gmail.com>
Subject: Re: Handling protocol versions
From: Stack <stack@duboce.net>
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=0015174a0e62382ccb04d1e1062b

--0015174a0e62382ccb04d1e1062b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 27, 2012 at 5:37 PM, Enis S=F6ztutar <enis.soz@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, an=
d
> 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 add=
ed
> 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-generate=
d#service

--0015174a0e62382ccb04d1e1062b--