That's a good point. We have use cases for the current APIs (security, Phoenix) but no motivating use case for HBASE-11125 yet. I would be better if we had one lined up.
On Sunday, May 18, 2014, lars hofhansl <la...@apache.org> wrote: > But note that such a high level interface will probably not allow access > at level necessary for Phoenix. > You can't eat your cake and keep it. For some performance you deep access > to HBase internals (RegionScanners, for example). At the same time, these > *are* internal. > > > I suppose to least we can do is marking these interfaces/classes clearly > (as we have started in 0.96 and later as being public/private/evolving, > etc). > > There's a use case for HBASE-11125, but to me at least it does not seem to > be Phoenix. But maybe I am wrong. > > > -- Lars > > > > ________________________________ > From: James Taylor <jtay...@salesforce.com <javascript:;>> > To: "dev@hbase.apache.org <javascript:;>" <dev@hbase.apache.org<javascript:;> > > > Sent: Thursday, May 15, 2014 6:47 PM > Subject: Re: On coprocessor API evolution > > > +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<javascript:;>> > 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) > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
