On Wed, Feb 12, 2014 at 12:46 PM, Gary Helmling <[EMAIL PROTECTED]> wrote:
I've always considered coprocessors to be the "kernel modules" of the HBase
world. They give you way more power than user-space programming, but come
with the cautions that if you make a mistake, you'll crash your whole
system or trigger unexpected behavior.

Given that, I don't think we should really be spending too much effort on
coprocessor API stability. If we make this a requirement, it can hamper the
ability of the HBase core developers to make good changes which really
improve the system. I don't think we're at the level of maturity as a
project where this is the right tradeoff, as of yet.

For what it's worth, the Linux kernel module API is also not
stable/compatible between versions. This document is a good read:

I do think we should seek to keep the interfaces stable through *patch*
level releases -- a bug fix shouldn't break a coprocessor API. But between
minor releases that add new features, it seems like an unnecessary

Todd Lipcon
Software Engineer, Cloudera

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB