Nicolas: Can you give an example of using @since to tag new hooks ? I searched hadoop and hbase codebase but didn't seem to find such annotation.
Cheers On Fri, May 16, 2014 at 1:18 AM, Nicolas Liochon <nkey...@gmail.com> wrote: > Hi, > > (With Apache still lagging on mails, it may be difficult to have a > discussion...) > > For 1.0+, I think that registering observer as proposed in 11125 works > well. > For 0.98, could we do something like this? > - new coprocessor hooks can be added between minor releases > - existing coprocessors hooks are not removed between minor releases > - a coprocessor can extend the default implementation. Binary > compatibility when migrating to a newer minor release is ensured. > - a coprocessor can implement directly the interface, but in this case the > application needs to be updated and recompiled between minor releases . > - new hooks are always tagged with @since. This helps the coprocessor > developer if he needs to support multiple minor version. > - between major release, everything can happen. > > fwiw, Java 8 supports default implementations in interfaces: > http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html > > Cheers, > > Nicolas > > > > > > On Thu, May 15, 2014 at 3: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) > > >
