Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of yuzhihong@gmail.com
 designates 209.85.213.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPcDmSvCCP14cZ1CPwTpzORceLJqDpw9ynXFdHD__t8q+UoKeA@mail.gmail.com>
References: 
 <CA+RK=_C+m6CDfEye39LzjeBR-Hij+ymHCt-wqwU2Cn_btZtaKQ@mail.gmail.com>
	<CAPcDmSvCCP14cZ1CPwTpzORceLJqDpw9ynXFdHD__t8q+UoKeA@mail.gmail.com>
Date: Fri, 16 May 2014 10:04:58 -0700
Message-ID: 
 <CALte62yTA0yKCYWQtJ4ihHisuNicbS7kemek6_06J1RJ4ZuYmw@mail.gmail.com>
Subject: Re: On coprocessor API evolution
From: Ted Yu <yuzhihong@gmail.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=089e0139fc84d39a8f04f9876999

--089e0139fc84d39a8f04f9876999
Content-Type: text/plain; charset=UTF-8

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

--089e0139fc84d39a8f04f9876999--