The goal is strictly Java. Right now they don’t even have a Java client. Where are the docs on their locks/leases?
-Jordan > On Jul 27, 2016, at 10:38 PM, Scott Blum <[email protected]> wrote: > > Seems very ambitious! > Looks like some of the most useful recipes like locks, leases, and > elections are built-in to etcd. > > On Wed, Jul 27, 2016 at 9:48 PM, Jordan Zimmerman < > [email protected]> wrote: > >> I know nothing about etcd/raft either. My motivation is more future >> thinking. >> >>> It would seem like a pretty large amount of work (essentially >>> a complete rewrite) >> >> I think the recipes can be saved. Very little of ZooKeeper is exposed in >> most of them (other than the paths). Internally, the Curator Framework >> stuff could be abstracted. I don’t think it would be that bad. >> >>> I wonder if we've collectively got enough spare cycles >> >> There’s no rush. It could be done in the background. It might be just you >> and me unless someone else steps up. I’m in for it if you are. >> >> -Jordan >> >>> On Jul 27, 2016, at 6:15 PM, Cameron McKenzie <[email protected]> >> wrote: >>> >>> hey Jordan, >>> Sounds like a good idea in theory (though I have no experience in >>> etcd/consol), but I wonder if we've collectively got enough spare cycles >> to >>> get it done. It would seem like a pretty large amount of work >> (essentially >>> a complete rewrite) to abstract all of the ZK concepts into something >> that >>> is shared across different backends. >>> cheers >>> >>> On Thu, Jul 28, 2016 at 3:15 AM, Jordan Zimmerman < >>> [email protected]> wrote: >>> >>>> Hello Devs, >>>> >>>> etcd/consul is starting to gain traction. Currently, there is no Java >>>> driver for it. Even if they do make a driver I doubt they’ll have high >>>> level patterns for it. I’m starting to wonder if we could refactor >> Curator >>>> so that it has a pluggable backend such that the same code (or close >>>> variations) could run on either ZooKeeper or etcd or whatever. >>>> >>>> Thoughts? >>>> >>>> -Jordan >> >>
