> While working on keeping bw compatibility for > https://issues.apache.org/jira/browse/HBASE-5371, I realized that it might > be a good idea to include the co-processor interfaces into the scope as
> well +1 Wire compatibility considerations should extend to dynamic RPC protocols/endpoints and extensibility of their custom protocols. Whatever choices are made, they will impact how coprocessor implementors can maintain cross version compatibility themselves. I think the general direction of using protobufs is good, most issues with cross-versioning of protocols and extensibility are handled. And it's reasonable for an implementor of an advanced API to deal with more implementation particulars than others (users). One thing I do worry about is some RPC layer change that breaks dynamic endpoints. That can't happen. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) ----- Original Message ----- > From: Enis Söztutar <[email protected]> > To: [email protected] > Cc: > Sent: Friday, February 17, 2012 5:30 PM > Subject: Re: HBase wire compatibility > > While working on keeping bw compatibility for > https://issues.apache.org/jira/browse/HBASE-5371, I realized that it might > be a good idea to include the co-processor interfaces into the scope as > well. Although they are marked as advanced API's, and even if you wrap them > under some java class, there will be need to access the functionality from > clients, and they should be treated the same way as 3 and 4. Just something > to consider until Thursday, I'll try to be there as well. > > Thanks, > Enis > > On Thu, Feb 16, 2012 at 4:54 PM, Stack <[email protected]> wrote: > >> On Thu, Feb 16, 2012 at 3:55 PM, Jeff Whiting <[email protected]> > wrote: >> > What I'm suggesting may not be possible but it seems like it is > worth >> > keeping in mind through the design and implementation process. >> > >> >> There is already proof that what you suggest is possible. asynchbase >> is a 'lighter', 'incomplete' but >> complete-enough-for-a-particular-purpose client that does much of what >> you talk of except the bit about being in another language. >> >> St.Ack >> >
