Home | About | Sematext search-lucene.com search-hadoop.com
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
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Re: DISCUSSION: 1.0.0


Copy link to this message
-
Re: DISCUSSION: 1.0.0
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:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/stable_api_nonsense.txt

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
restriction.

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