My first reaction to the code, also at a high-level browse, was that it is way over-complicated. Might just be the builder style, which I also don't care for. I had to go several levels deep through interfaces and impls to see the code that does anything of meaning, which makes for a high learning curve and a debugging headache.
So, it's not clear to me why anyone would use this over zkClient, except that you have provided a pluggable retry style, which is nice. Any other major benefits I'm missing from a scan? C On Oct 11, 2011 4:53 PM, "Jordan Zimmerman" <[email protected]> wrote: > The major raison d'être for Curator is to make adding "recipes" much > easier. Using the Curator Framework APIs you can easily build new > usages/recipes and not worry about connection management. > > -JZ > > On 10/11/11 1:46 PM, "Ted Dunning" <[email protected]> wrote: > > >What I prefer to see in this context is a method that takes a closure that > >does the desired mutation and which encapsulates the necessary read, > >modify, > >write, retry logic. > >
