+1 to what Lars said.
On Sat, May 17, 2014 at 11:01 PM, lars hofhansl <la...@apache.org> wrote: > We've seen similar issues with Filters. Those are good rules to follow. > > > > ________________________________ > From: Vladimir Rodionov <vladrodio...@gmail.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org> > Sent: Friday, May 16, 2014 10:59 AM > Subject: Re: On coprocessor API evolution > > > 1) Have default implementations (abstract classes) for every interface from > Coprocessor API. > 2) Advise coprocessor users not to implement interface directly but sub > class default impl. > 3) Preserve backward compatibility by adding only new hooks/methods > 4) DO NOT CHANGE existing API (no method renaming, method parameter type > changes etc) > 5) Have a regression tests to check backward compatibility. > > -Vladimir > > > > > On Fri, May 16, 2014 at 9:13 AM, Michael Segel <michael_se...@hotmail.com > >wrote: > > > Until you move the coprocessor out of the RS space and into its own > > sandbox… saying security and coprocessor in the same sentence is a joke. > > Oh wait… you were serious… :-( > > > > I’d say there’s a significant rethink on coprocessors that’s required. > > > > Anyone running a secure (kerberos) cluster, will want to allow system > > coprocessors but then write a coprocessor that reject user coprocessors. > > > > Just putting it out there… > > > > On May 15, 2014, at 2:13 AM, 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) > > > > >
