I was thinking from the point of view that if you want to provide ZAB
as a library, then the library will have to provide an RPC mechanism
for talking to other members of the quorum, and a means to persist
updates to disk before responding, and _then_ provide a ZAB
implementation somewhere in between. This doesn't seem much lighter
than BK.

I think it's a worthwhile thing to pursue, but I disagree that a
separate project is a better way to doing it. If this is an intern
project, expecting them to reimplement ZAB might be a bit of a large
ask (depending on the internship length and the intern
themselves). An investigation into splitting the user interface layer
of zookeeper and ZAB seems itself to be a nice chunk to work on, and
it has the advantage that even if the changes don't get merged into
trunk, there will be a clearer picture as to why they can't be

You can read from a ledger while it is being written to, but right now
it's polling. Twitter are working on some changes to make it more
notification like to reduce latency between the primary writing and
the secondary reading.

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