I can see two reasons for decoupling Zab: 1- You'd like to be able to plug in new algorithms or at least make a clear separation of the replication protocol and the logic of the service. 2- You'd like to have an implementation of Zab that you could use for other things, like a kv store.
I think you're focusing more on 2. You can definitely use Zab for other things, and I'm all for it. It would probably be better to just implement the protocol from scratch rather than extract it from ZooKeeper. In fact, it might be worth having a look at ZK-30 (old one, huh?). In the case of reimplementing it, it might be worth doing it outside ZooKeeper, as a separate project. It could be an incubated project. Hope it helps! -Flavio On 31 May 2014, at 22:29, Michi Mutsuzaki <mi...@cs.stanford.edu> wrote: > Hi, > > I'm hosting an intern this summer. One project I've been thinking > about is to decouple zab from zookeeper. There are many use cases > where you need a quorum based replication, but the hierarchical data > model doesn't work well. A smallish (~1GB?) replicated key-value store > with millions of entires is one such example. The goal of the project > is to decouple the consensus algorithm (zab) from the data model > (zookeeper) more cleanly so that the users can define their own data > models and use zab to replicate the data. > > I have 2 questions: > > 1. Are there any caveats that I should be aware of? For example, > transactions need to be idempotent to allow fuzzy snapshotting. > 2. Is this useful? Personally I've seen many use cases where this > would be very useful, but I'd like to hear what you guys think. > > Thanks! > --Michi
