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 <[email protected]> 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 <[email protected]> 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 >> >
