hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject On coprocessor API evolution
Date Thu, 15 May 2014 01:13:17 GMT
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

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

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

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)

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