Are folks down with purging CoprocessorProtocol in 0.96 and all of its
associated machinery?

For example, Andrew Purtell says "I'd be +1 with dropping
CoprocessorProtocol from 0.96 and up, given all of the other (deliberate)
incompatibilities posed with RPC going from 0.94 to 0.96 and up." [2].

CoprocessorProtocol is how we did dynamic endpoints before 0.96/trunk where
we are moving to protobuf'ing all rpc Interactions.  Dynamic endpoints are
now done using CoprocessorService where you define your endpoint as a
protobuf Service [1].

Cons:
+ Any current coprocessor dynamic endpoint will need to be refactored to
run on 0.96
+ We will have to support two very different underpinnings for an exotic
though critical feature (We'd have to do this if we wanted to deprecate to
purge in another release)

Pros:
+ Purge a bunch of code.  Simplify RPC.  Save a bunch of effort making sure
both mechanisms work.  One, "cleaner" (though perhaps more verbose) way of
implementing dynamic endpoints.

I'm in favor of purge without deprecation.  I've done a few convertions.  I
volunteer to help out anyone who needs to make the transition.

St.Ack

1. https://issues.apache.org/jira/browse/HBASE-6789
2. http://goo.gl/fSTLM

> We will have to support two very different underpinnings for an exotic though
critical feature

I think this means supporting CoprocessorProtocol based endpoint RPC in
0.94 and PB based endpoint RPC in 0.96+. If so then yes.

Pro:
+ Normalizes interactions over RPC with HBase. Everything speaks protobufs.

The fact is HBase 0.96 has a redesigned RPC stack, and coprocessor
endpoints wrap RPC. This change is IMO a necessary consequence of other
changes we have already decided upon and committed.

I can help out with transitions from a 0.94 world to a 0.96+ one too.
On Thu, Dec 20, 2012 at 1:20 PM, Stack <[EMAIL PROTECTED]> wrote:

> Are folks down with purging CoprocessorProtocol in 0.96 and all of its
> associated machinery?
>
> For example, Andrew Purtell says "I'd be +1 with dropping
> CoprocessorProtocol from 0.96 and up, given all of the other (deliberate)
> incompatibilities posed with RPC going from 0.94 to 0.96 and up." [2].
>
> CoprocessorProtocol is how we did dynamic endpoints before 0.96/trunk where
> we are moving to protobuf'ing all rpc Interactions.  Dynamic endpoints are
> now done using CoprocessorService where you define your endpoint as a
> protobuf Service [1].
>
> Cons:
> + Any current coprocessor dynamic endpoint will need to be refactored to
> run on 0.96
> + We will have to support two very different underpinnings for an exotic
> though critical feature (We'd have to do this if we wanted to deprecate to
> purge in another release)
>
> Pros:
> + Purge a bunch of code.  Simplify RPC.  Save a bunch of effort making sure
> both mechanisms work.  One, "cleaner" (though perhaps more verbose) way of
> implementing dynamic endpoints.
>
> I'm in favor of purge without deprecation.  I've done a few convertions.  I
> volunteer to help out anyone who needs to make the transition.
>
> St.Ack
>
>
>
>
>
> 1. https://issues.apache.org/jira/browse/HBASE-6789
> 2. http://goo.gl/fSTLM
>

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Thanks Andrew.

I've actually messed up in that this issue has already been discussed back
in September and consensus was to go with purging CoprocessorProtocol [1
and 2].  Sorry for the noise.  Let me go  make a patch.

St.Ack

1.
http://mail-archives.apache.org/mod_mbox/hbase-dev/201209.mbox/%3CCADfYSXTvqEu3SifyWdZCi9kKPw1Hf9EoaKVGFOCbwRpSkdaCng%40mail.gmail.com%3E
2. https://issues.apache.org/jira/browse/HBASE-6895

On Thu, Dec 20, 2012 at 2:10 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> > We will have to support two very different underpinnings for an exotic
> though
> critical feature
>
> I think this means supporting CoprocessorProtocol based endpoint RPC in
> 0.94 and PB based endpoint RPC in 0.96+. If so then yes.
>
> Pro:
> + Normalizes interactions over RPC with HBase. Everything speaks protobufs.
>
> The fact is HBase 0.96 has a redesigned RPC stack, and coprocessor
> endpoints wrap RPC. This change is IMO a necessary consequence of other
> changes we have already decided upon and committed.
>
> I can help out with transitions from a 0.94 world to a 0.96+ one too.
>
>
> On Thu, Dec 20, 2012 at 1:20 PM, Stack <[EMAIL PROTECTED]> wrote:
>
> > Are folks down with purging CoprocessorProtocol in 0.96 and all of its
> > associated machinery?
> >
> > For example, Andrew Purtell says "I'd be +1 with dropping
> > CoprocessorProtocol from 0.96 and up, given all of the other (deliberate)
> > incompatibilities posed with RPC going from 0.94 to 0.96 and up." [2].
> >
> > CoprocessorProtocol is how we did dynamic endpoints before 0.96/trunk
> where
> > we are moving to protobuf'ing all rpc Interactions.  Dynamic endpoints
> are
> > now done using CoprocessorService where you define your endpoint as a
> > protobuf Service [1].
> >
> > Cons:
> > + Any current coprocessor dynamic endpoint will need to be refactored to
> > run on 0.96
> > + We will have to support two very different underpinnings for an exotic
> > though critical feature (We'd have to do this if we wanted to deprecate
> to
> > purge in another release)
> >
> > Pros:
> > + Purge a bunch of code.  Simplify RPC.  Save a bunch of effort making
> sure
> > both mechanisms work.  One, "cleaner" (though perhaps more verbose) way
> of
> > implementing dynamic endpoints.
> >
> > I'm in favor of purge without deprecation.  I've done a few convertions.
>  I
> > volunteer to help out anyone who needs to make the transition.
> >
> > St.Ack
> >
> >
> >
> >
> >
> > 1. https://issues.apache.org/jira/browse/HBASE-6789
> > 2. http://goo.gl/fSTLM
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

I think it's good to get this out there again, it's going to be a big
change.
On Thu, Dec 20, 2012 at 3:40 PM, Stack <[EMAIL PROTECTED]> wrote:

> Thanks Andrew.
>
> I've actually messed up in that this issue has already been discussed back
> in September and consensus was to go with purging CoprocessorProtocol [1
> and 2].  Sorry for the noise.  Let me go  make a patch.
>
> St.Ack
>
> 1.
>
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201209.mbox/%3CCADfYSXTvqEu3SifyWdZCi9kKPw1Hf9EoaKVGFOCbwRpSkdaCng%40mail.gmail.com%3E
> 2. https://issues.apache.org/jira/browse/HBASE-6895
>
>
>
> On Thu, Dec 20, 2012 at 2:10 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
>
> > > We will have to support two very different underpinnings for an exotic
> > though
> > critical feature
> >
> > I think this means supporting CoprocessorProtocol based endpoint RPC in
> > 0.94 and PB based endpoint RPC in 0.96+. If so then yes.
> >
> > Pro:
> > + Normalizes interactions over RPC with HBase. Everything speaks
> protobufs.
> >
> > The fact is HBase 0.96 has a redesigned RPC stack, and coprocessor
> > endpoints wrap RPC. This change is IMO a necessary consequence of other
> > changes we have already decided upon and committed.
> >
> > I can help out with transitions from a 0.94 world to a 0.96+ one too.
> >
> >
> > On Thu, Dec 20, 2012 at 1:20 PM, Stack <[EMAIL PROTECTED]> wrote:
> >
> > > Are folks down with purging CoprocessorProtocol in 0.96 and all of its
> > > associated machinery?
> > >
> > > For example, Andrew Purtell says "I'd be +1 with dropping
> > > CoprocessorProtocol from 0.96 and up, given all of the other
> (deliberate)
> > > incompatibilities posed with RPC going from 0.94 to 0.96 and up." [2].
> > >
> > > CoprocessorProtocol is how we did dynamic endpoints before 0.96/trunk
> > where
> > > we are moving to protobuf'ing all rpc Interactions.  Dynamic endpoints
> > are
> > > now done using CoprocessorService where you define your endpoint as a
> > > protobuf Service [1].
> > >
> > > Cons:
> > > + Any current coprocessor dynamic endpoint will need to be refactored
> to
> > > run on 0.96
> > > + We will have to support two very different underpinnings for an
> exotic
> > > though critical feature (We'd have to do this if we wanted to deprecate
> > to
> > > purge in another release)
> > >
> > > Pros:
> > > + Purge a bunch of code.  Simplify RPC.  Save a bunch of effort making
> > sure
> > > both mechanisms work.  One, "cleaner" (though perhaps more verbose) way
> > of
> > > implementing dynamic endpoints.
> > >
> > > I'm in favor of purge without deprecation.  I've done a few
> convertions.
> >  I
> > > volunteer to help out anyone who needs to make the transition.
> > >
> > > St.Ack
> > >
> > >
> > >
> > >
> > >
> > > 1. https://issues.apache.org/jira/browse/HBASE-6789
> > > 2. http://goo.gl/fSTLM
> > >
> >
> >
> >
> > --
> > 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)