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) >
