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)
