hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jtay...@salesforce.com>
Subject Re: On coprocessor API evolution
Date Fri, 16 May 2014 01:47:28 GMT
+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)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message