I agree the ability to compose coprocessors in order to extend behavior is
a key capability that we should not throw out.

I think the current Observer APIs could probably do with a bit of
reorganization to make them a little more accessible and comprehensible.  I
think there is also an emerging need to see if we can define some subset of
these APIs that we can stabilize for easier public consumption, while
keeping the rest of the APIs free to evolve as needed as HBase internals
change (since these are an extension mechanism for internal behaviors).
 I'm not sure we've really seen enough commonality emerge yet to say what
those APIs are though.  We could try to define the public subset as those
involved in client requests, but flush and compaction, for example, can
also be triggered by client requests.  And my own use of coprocessor APIs
lately has been focused on overriding the flush and compaction behaviors,
not on client requests.

I think the best place to start is by breaking up some of the current APIs,
grouping them around behaviors or areas of functionality.  Whether we call
some of these "coprocessors" and others "plugins" is a question of
branding.  I do think it's important to figure out which we can stabilize
and offer longer term contracts for.  But whatever we call them, I strongly
agree that we should maintain the "mixin" / composition approach and not
return to a simple fixed inheritance scheme.

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