hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: On coprocessor API evolution
Date Fri, 16 May 2014 17:04:58 GMT
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 <nkeywal@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 <apurtell@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)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message