+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 <apurt...@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) >
