zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Stein <charmal...@allthingshadoop.com>
Subject Re: ANN: Curator - Netflix's ZooKeeper library
Date Wed, 12 Oct 2011 04:23:34 GMT
I might have some time early next week but the Scala ZK lib I use is built
up from https://github.com/twitter/scala-zookeeper-client and I have been
meaning to take some of the additions I have made implementing that (mostly
new tests and some more boiler plate too) but now maybe I can go through
some of your recipes and come up with something useful for Scala folks (like
I did recently for Cassandra users for Hector, in my humble opinion).

Most likely/realistically I can steal an iteration away from my current
workload the first week of November now that I am afforded time to work on
open source.

On Tue, Oct 11, 2011 at 10:55 PM, Jordan Zimmerman
<jzimmerman@netflix.com>wrote:

> It might be possible to put a Scala wrapper around the recipe classes. I'll
> see what I can do - or if you want to contribute that ;)
>
> ====================
> Jordan Zimmerman
>
> On Oct 11, 2011, at 4:40 PM, "Joe Stein" <charmalloc@allthingshadoop.com>
> wrote:
>
> > Its not written in Scala :( otherwise the contribution is great in having
> recipes for more quick start ready, try to get more new users, to build
> right away but I like the lower level access at times (myself as a zk dev
> user) I need to find time to release the twitter Scala client I have been
> using and have grown from their wrapper.
> >
> > Nothing bad, some good stuff.  First post to this list for me.  Thanks to
> all an everyone for making a kickass server I use everyday.  The client
> Netflix released would have helped my initial learning curve but I would
> have ended up where I am now the same.
> >
> > /*
> > Joe Stein
> > http://www.medialets.com
> > Twitter: @allthingshadoop
> > */
> >
> > On Oct 11, 2011, at 7:00 PM, Camille Fournier <camille@apache.org>
> wrote:
> >
> >> 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" <jzimmerman@netflix.com>
> 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" <ted.dunning@gmail.com> 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.
> >>>
> >>>
> >
>



-- 

/*
Joe Stein
http://www.linkedin.com/in/charmalloc
Twitter: @allthingshadoop
*/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message