It's great to hear that others are interested in this initiative. Thanks for working on the spec Kanak.
Regarding the node.js participant, here are some ZooKeeper clients that I've investigated: - node-zookeeper-client<https://github.com/alexguan/node-zookeeper-client> - Feature-parity with official ZK client - Well documented and still maintained - API is consistent with Node.js libraries - Written entirely in Node, making it more portable; however, the behavior is not guaranteed to be consistent with the official ZK client - node-zookeeper <https://github.com/yfinkelstein/node-zookeeper> - Is actually an interface for the official ZK C API, so behavior could be assumed to be correct - Less portable because it must be built for every platform - API is consistent with the official ZK API - node-zkplus <https://github.com/mcavage/node-zkplus> - API modeled after fs API - Built on top of node-zookeeper Best, Kevin On Mon, Sep 23, 2013 at 11:33 AM, Kanak Biscuitwala <[email protected]>wrote: > +1. Jason and I will work on the spec and will point you to it once it's > ready. > > Kanak > ________________________________ > > Date: Mon, 23 Sep 2013 11:30:23 -0700 > > Subject: Re: Node.js Helix Participant > > From: [email protected] > > To: [email protected] > > > > Hi Kevin, > > > > This will be a great addition. We, at LinkedIn are also seeing the need > > to have Helix Participant in other languages such as Python. Python > > already has some good zk libraries. I am not sure if we have good zk > > libraries in node.js/javascript (Patrick, might have some suggestions). > > > > I think it will definitely help the community and we are interested in > > python implementation. > > > > The best way to approach this would be to first come up with a minimal > > spec required for the participant. Currently things that participant > > does is > > > > > > * Create a ephemeral node under liveinstances when it starts > > * Listen to messages node for commands from the controller > > * Update the current state with the result of the command. > > > > thanks, > > Kishore G > > > > > > > > > > On Thu, Sep 19, 2013 at 11:24 AM, Kevin Gao > > <[email protected]<mailto:[email protected]>> wrote: > > Hi all, > > > > My colleagues at Box and I are considering developing a Node.js based > > Helix participant library as an open source project. I first and > > foremost wanted to gauge how useful this would be in the community's > > use cases. For us, the main service runs on Node.js and is the actual > > owner of resources, while we treat Helix as the one, shared source of > > truth regarding which nodes own what resources. This introduces a split > > brain scenario between the two. In the mean time, we have introduced > > health checking and state validation to ensure that the two are > > consistent. Additionally, we have developed a local protocol for > > communicating state transitions. However, maintaining this architecture > > leaves room for inconsistency as well as significant slow down in > > developing actual application logic. > > > > What we think would be extremely useful to us is to have write a > > JavaScript-based participant library. This involves a few major > > questions to be answered first: > > > > * Is the community interested in the availability of this project? > > * Is there a reliable, vetted ZooKeeper client for Node.js? > > * What components of the Helix library need to be ported over? > > * Related to the previous question, what feature set is required at > > minimum for a production-ready library? > > * How difficult would it be to maintain this library in parallel to the > > main Helix distribution? > > > > My team and I would appreciate any feedback or input you have! > > > > Best, > > Kevin > > > > -- > > Kevin Gao > > [email protected]<mailto:[email protected]> > > -- Kevin Gao [email protected]
