hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: On coprocessor API evolution
Date Thu, 15 May 2014 17:47:02 GMT
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.
>
>
The above quote is mine.

I had just read a user mail on the phoenix list where someone thought that
phoenix had been broken going from 0.98.1 to 0.98.2 (apparently its fine).

Lets write up agreement.  We've talked this topic a bunch.

1. No guarantees minor version to minor version?  APIs can be broken any
time.
2. API may change across minor versions but SHOULD not break existing users
(No guarantees!)?
3. API may change across minor versions but WILL not break existing users?

Any other permutations? (I'm good w/ #2 and #3.  #1 will just make it so no
one will use CPs).



> 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.
>
>
Sounds good.



> 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.
>

+1 on HBASE-11127.
St.Ack

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