You asked for feedback, I gave it. You know nothing about what I think of maven, guice, spring, or hibernate, so why bring them up?
There's a middle ground between Curator and zkClient, and I personally would love to see that middle ground reached. Anyway, I've never made a decision to use a library or not based on the conditions you listed below (unless there were actual usability issues related to them, which for me there weren't in zkClient), so I'm pretty sure I am not your target audience. But I know there are many here that would be turned off by those reasons and it is great to give them a different choice. C On Tue, Oct 11, 2011 at 7:34 PM, Jordan Zimmerman <[email protected]> wrote: > It amazes me that people comment on this or that library that it's too > complicated but then don't blanch to use things such as Maven, Guice, Spring, > Hibernate, etc. > > Issues with zkClient: > * Very poor documentation (is there any?) > * Far too coupled for my taste. zkClient covers far too much scope. > * Error handling is very weak (everything becomes RuntimeException) > * Hard coded retry mechanism > * Some bad anti-patterns > ** ZkClient constructor leaks "this" ref > ** lots of synchronized/lock blocks > > Curator is much more modular. You could use just the Client package (which > isn't complicated at all). The recipes are completely de-coupled making them > more reusable/extendable. I believe a new ZK user would have a much easier > time with Curator than zkClient. My experience with users at Netflix confirms > this. Our users can concentrate on the recipes (which is what they're really > interested in) and not worry about the details of managing ZK interaction. > > -JZ > ________________________________________ > From: Camille Fournier [[email protected]] > Sent: Tuesday, October 11, 2011 4:00 PM > To: [email protected] > Subject: Re: ANN: Curator - Netflix's ZooKeeper library > > 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. >> >> >
