Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CADfYSXTvqEu3SifyWdZCi9kKPw1Hf9EoaKVGFOCbwRpSkdaCng@mail.gmail.com>
References: 
 <CADfYSXTvqEu3SifyWdZCi9kKPw1Hf9EoaKVGFOCbwRpSkdaCng@mail.gmail.com>
Date: Thu, 20 Sep 2012 12:08:02 -0700
Message-ID: 
 <CA+RK=_AnB0r-E+jVKDBvonzALb2D3ocor1QyD5u6fisdOsANHA@mail.gmail.com>
Subject: Re: Coprocessor Endpoint RPC and 0.96 backwards compatibility
From: Andrew Purtell <apurtell@apache.org>
To: dev@hbase.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 20, 2012 at 12:02 PM, Gary Helmling <ghelmling@gmail.com> wrote:
> Now that HBASE-5448 is in trunk, we have support for defining
> coprocessor endpoints as protocol buffer based Services, using PB
> serialization for the endpoint RPC calls.  This is accomplished via a
> new set of HTable methods (HTable.coprocessorService*).  As part of
> the initial implementation, AccessControllerProtocol was converted to
> a PB-based Service, and individual JIRA issues have been opened to
> convert the remaining CoprocessorProtocol-based implementations that
> we ship.
[...]
> Given that 0.96 has been dubbed "the singularity", with some
> acknowledgement that we will be breaking backward compatibility,
> should we make an exception to the normal deprecation process and
> completely remove the CoprocessorProtocol-based support in 0.96?  This
> would allow us to drop Writable support from coprocessor endpoint
> RPCs.  Or should we leave CoprocessorProtocol support deprecated, to
> be removed in 0.98?
>
> On the one hand, coprocessors and CoprocessorProtocol RPC have been
> described as an experimental feature with an evolving interface.  On
> the other hand, the switch over from CoprocessorProtocol to PB Service
> implementations for anyone developing their own endpoints will be
> semi-painful, with a new requirement to define a .proto file, compile
> with protoc, and very different client usage exposing the PB
> interfaces.
>

It seems inevitable that any users of CoprocessorProtocol now will
suffer this pain eventually. Given that coprocessors are in an
experimental state and we are still iterating toward a stable design
-- I think a reasonable expectation is for that CP API design
stability somewhere in the neighborhood of 0.98 or 1.0 -- doing it
earlier rather than later is the better course of action. There can
only be more users of CoprocessorProtocol as time goes on, until it is
removed, either at the 0.96 "singularity" or after a
deprecation-and-removal cycle into 0.98.

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)