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