I like the idea of removing the dependency on zkclient but have few questions on the approach.

"This will allow for more modularity and remove deployment cadence dependency among ZK-related classes and helix-core classes. Additionally, those who wish to use Helix's ZK-related features without explicitly using helix-core or Task Framework could do so by simply importing zookeeper-api module."

- How can we achieve this? Are we planning to make release these modules independent of each other. 
- Users should use Curator if they want ZK related features (make it easy to use ZK) Helix has a different goal (making it easy to build distributed systems).

- Why not just pull the code into a separate package within helix-core as the first step and think of moving it to a separate module at a later time.

Thanks
Kishore G

On Thu, Jan 23, 2020 at 5:38 PM Hunter Lee <narendly@gmail.com> wrote:
I added a short wiki describing this in GitHub: https://github.com/apache/helix/wiki/New-Modules-for-Apache-Helix


On Tue, Jan 21, 2020 at 2:45 PM Hunter Lee <narendly@gmail.com> wrote:
It seems that it would be beneficial to separate ZkClient and its supporting classes from IOItec into a separate module. This work includes doing away with IOItec library altogether. We've made some bug fixes to their implementation and noticed that some of their newer versions aren't backward-compatible. 

This may require an addition of another module, say helix-common, to resolve circular dependencies among the existing modules.

This will allow for more modularity and remove deployment cadence dependency among ZK-related classes and helix-core classes. Additionally, those who wish to use Helix's ZK-related features without explicitly using helix-core or Task Framework could do so by simply importing zookeeper-api module.

I'll be starting this work in a PR and let me know if you have any feedback!

Hunter