Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of jtaylor@salesforce.com
 designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+RK=_C+m6CDfEye39LzjeBR-Hij+ymHCt-wqwU2Cn_btZtaKQ@mail.gmail.com>
References: 
 <CA+RK=_C+m6CDfEye39LzjeBR-Hij+ymHCt-wqwU2Cn_btZtaKQ@mail.gmail.com>
Date: Thu, 15 May 2014 18:47:28 -0700
Message-ID: 
 <CAG_TOPC-wwBnuL0JQJqKaOMQD4XqQo0ScBvcM4-VnTOm_1K7zw@mail.gmail.com>
Subject: Re: On coprocessor API evolution
From: James Taylor <jtaylor@salesforce.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a1133e4caa36a7d04f97a986a

--001a1133e4caa36a7d04f97a986a
Content-Type: text/plain; charset=UTF-8

+1 to HBASE-11125. Current incarnation of coprocessors expose too much of
the guts of the implementation.


On Wed, May 14, 2014 at 6:13 PM, Andrew Purtell <apurtell@apache.org> wrote:

> Because coprocessor APIs are so tightly bound with internals, if we apply
> suggested rules like as mentioned on HBASE-11054:
>
>       I'd say policy should be no changes to method apis across minor
> versions
>
> This will lock coprocessor based components to the limitations of the API
> as we encounter them. Core code does not suffer this limitation, we are
> otherwise free to refactor and change internal methods. For example, if we
> apply this policy to the 0.98 branch, then we will have to abandon further
> security feature development there and move to trunk only. This is because
> we already are aware that coprocessor APIs as they stand are insufficient
> still.
>
> Coprocessor APIs are a special class of internal method. We have had a
> tension between allowing freedom of movement for developing them out and
> providing some measure of stability for implementors for a while.
>
> It is my belief that the way forward is something like HBASE-11125. Perhaps
> we can take this discussion to that JIRA and have this long overdue
> conversation.
>
> Regarding security features specifically, I would also like to call your
> attention to HBASE-11127. I think security has been an optional feature
> long enough, it is becoming a core requirement for the project, so should
> be moved into core. Sure, we can therefore sidestep any issues with
> coprocessor API sufficiency for hosting security features. However, in my
> opinion we should pursue both HBASE-11125 and HBASE-11127; the first to
> provide the relative stability long asked for by coprocessor API users, the
> latter to cleanly solve emerging issues with concurrency and versioning.
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

--001a1133e4caa36a7d04f97a986a--