Not to be too buzzword-compliant, but I've found the FSM module in Akka to be really great for modeling, uhh, FSMs, and the use of ZooKeeper makes one think a lot in terms of FSMs, so a Scala/Akka/FSM-based client it might be a fruitful path.
.. Adam On Tue, Oct 11, 2011 at 9:23 PM, Joe Stein <[email protected]>wrote: > 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 > <[email protected]>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" <[email protected] > > > > 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 <[email protected]> > > 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" <[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. > > >>> > > >>> > > > > > > > > > -- > > /* > Joe Stein > http://www.linkedin.com/in/charmalloc > Twitter: @allthingshadoop > */ >
